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Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Prufungsantrag gem. § 44 PatG ist gestellt 

(§) System und Verfahren zur Verteilung von Automatisierungsdaten (Automation Data Distrubution, abqekurzt: 
ADD) 

@ Die vorfiegende Erfindung zielt auf ein System und Ver- 
fahren zur automatisierten Datenverteilung. Im besonde- 
ren bietet die vorliegende Erfindung ein System zur Ver- 
teilung von Automatisierungsdaten, welches System- 
komponenten auf der Planungsebene (zum Beispiel kauf- 
manhischen Softwareanwendungen) und Systemkompo- 
nenten auf der Steueruhgsebene (zum Beispiel Anwen- 
dungen der Fabrikautomation) ermoglicht, durch die Ver- 
wendung vollstandig codierter Datagramme einfach mit- 
einander zu kommunizieren. 
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Beschreibung 
HINTERGRUND DER ERFINDUNG 
1 . Umfeld der Erfindung 

Die vorliegende Erfindung bewegt sich allgemein im Umfeld der Fabrikautomation. Genauer gesagt beschreibt sie ein 
Verfahren zur Dateqverteilung zwischen Anwendungen der Fabrikautomation und Softwareanwendungen aus dem IT- 
Bereich. 

2. Stand der Technik im Umfeld der Erfindung 



Automatisierungstechnik und betriebswirtschaftliche Datenverarbeitung haben sich fiber Jahre hinweg parallel und re- 
lativ unabhangig voneinander entwickelt. Seit geraumer Zeit wird jedoch die Wichtigkeit eines transparenten und zeitna- 

15 hen Datenflusses zwischen alien Aspekten und Teilbereichen eines Untemehmens erkannt. Fabrikautomation und kauf- 
mannische Softwareanwendungen werden dabei als integrale Bestandteile eines fibergeordneten Datenfluss-Prozesses 
betrachtet. Der Begriff "Manufacturing Execution System" ("MES") - im Deutschen auch der Begriff "Vertikale Integra- 
tion" - wird benutzt, um diese Integration anzusprechen. 

MES ermdglicht es kaufmannischen Anwendungen, direkt auf Produktionsdaten zuzugreifen. Dies ist sinnvoll zur 

20 Uberwachung der Prozesssteuerung: zum Beispiel fur Visualisierung (HMI), Alarmierung, Femwartung und Fernkonfi- 
guration, und fur Leitsysteme ("SCAD A"). Desweiteren eignet sich MES fur die Sammlung und Auswertung von Pro- 
zessdaten fur Planungszwecke, zum Beispiel im Rahmen von Produktionsplanungs- und -steuerungssystemen (PPS/ 
ERP) Manufacturing-Mangement-Information-Systeme (MMI) und zur Erfassung von Produktionsdaten. Schliesslich 
, gibt es eine wachsende Zahl von Softwareanwendungen, die direkt mit Automatisierungskomponenten kommunizieren, 

25 um Daten von Sensoren und anderen externen Datenquellen zu erfassen. Beispiele umfassen die Gebaudeautomation, 
Umwelttechnik, und Laboranweridungen, in denen keine Echtzeiteigenschaften gefordert sind. 

Zusammengefasst: MES zielt auf einen direkteren, zeitnahen Datenfluss zwischen Automatisierungskomponenten 
und IT-Softwareanwendungen. In vielen Unternehmen des produzierenden Gewerbes konnen hierdurch Qualitatsverbes- 
serungen erzielt und Pufferzeiten verkurzt werden. Im gegenwartigen Wettbewerbsumfeld, das durch Globalisierung, 

30 Buit-to-Order (Anfertigung nach Kundenspezifikation) und Just-in-Time-Produktion (Minimierung von Lagerzeiten) ge- 
kennzeichnet ist, lassen sich hierdurch wichtige Produktivitatsgewinne erzielen. 

Ein problemloser direkter Datenaustausch zwischen der Steuerungsebene (zum Beispiel automatisierungstechnischen 
Anwendungen) und der Planungsebene (zum Beispiel betriebswirtschaftliche Anwendungen) war bisher praktisch na- 
hezu unmoglich, da beide Bereiche isoliert voneinander und fur auf unterschiedliche Zwecke entwickelt wurden. Sie ver- 

35 wendeten fur gewohnlich zueinander inkompatible Verfahren und Paradigmen zur Datenubertragung. So hatten zum Bei- 
spiel Ubertragungsprotokolle und -medien der Steuerungsebene kein Pendant auf der Planungsebene. Des weiteren wur- 
den auf der Steuerungsebene zahlreiche untereinander inkompatible Ubertragungsprotokolle und -medien verwendet, 
was einem durchgangigen Datenfluss zwangslaufig entgegensteht. Die traditionelle Industrielle Kommunikation wird am 
besten durch eine Vielzahl hersteller- und geratespezifischer Ubertragungs- und Anwendungsprotokolle charakterisiert 

40 (zum Beispiel 3946R, RK512, Modbus, IEC870, Mewtocol, AK, MPI, LSV2, Interbus, Devicenet, MSV2), von denen 
die meisten in der Office- Welt praktisch unbekannt sind, 

Der Einsatz von Industrieprotokollen fiir einen durchgangigen Datenfluss zur Planungsebene scheitert oft bereits 
daran, dass eine Uberwachung der unteren Protokollschichten erforderlich ist, die jedoch von modemen Rechnerarchi- 
tekturen nicht unterstutzt wird. So erfordert beispielsweise das M-Bus-Protokoll (ein Protokoll aus dem Bereich der 

45 Fernwirktechnik) nach dem Empfang eines Telegramms eine Pause fur die Dauer von 11 Bit, bevor ein Antworttele- 
gramm gesendet werden kann. Das ist mit aktiven (gepufferten) seriellen Schnittstellenkarten, wie sie in heutigen Com- 
putern vielfach eingesetzt werden, nicht zu machen. 

Die Ablaufverfahren (bzw. Paradigmen) von Steuerungsebene und Planungsebene unterscheiden sich grundlegend. 
Auf der Steuerungsebene werden sequenzielle Ablaufe mit Abfragearchitekturen (Master/Slave) verwendet, um ein de- 

50 terministisches Zeitverhalten und damit Echtzeitfahigkeit zu erreichen. Im Gegensatz dazu benutzen Softwareanwen- 
dungen aus dem IT-Bereieh oft ereignisgesteuerte Architekturen. Die zyklischen, sequenziellen Programmstrkturen, die 
auf der Steuerungsebene verwendet werden, konnen nicht einfach auf die im IT-Bereich ublichen Multitasking-Rechner 
ubertragen werden, da sie einen Grossteil der Rechenleistung beanspruchen wurden. Dementsprechend ist es weder sinn- 
voll noch einfach fur einen Windows-PC, mehrere hundert Mai pro Sekunde Sensordaten abzufragen, was erforderlich 

55 ware, um einen Sensor zu iiberwachen. PCs und PC-Software eignen sich wesentlich besser zur ereignisgesteuerten Ver- 
arbeitung von Anderungsdaten anstatt zur kontinuierlichen zyklischen Uberwachung von Datenquellen (welches eher 
die Domane von speicheiprogrammierbaren Steuerungen ist). 

Die meisten Industrieprotokolle wurden fur eirien eng umgrenzten Verwendungszweck entwickelt, d. h. fiir die Kom- 
munikation mit einem spezifischen Typ von Peripheriegerat, nicht jedoch fiir den standardisierten Datenaustausch zwi- 

60 schen Systemen unterschiedlicher Architektur. Auch vermischen Industrieprotokolle zuweilen mehrere Schichten des 
ISO/OSI-Schichtenmodells. Dies stellt ein grosses Hindemis fur die Nutzung solcher Protokolle in Office- Anwendungen 
und modernen Netzwerkumgebungen dar. Ein Protokoll, welches sich uber mehrere Schichten des ISO/OSI-Modells er- 
streckt, ist unflexibel und oft nur schwierig mit anderen Anwendungen und/oder Ubertragungsmedien zu verkniipfen. 
Die Verkniipfung mit Office-Anwendungen ware zum Beispiel wesentlich einfacher, wenn es "nur" um die Umsetzung 

65 von unterschiedlichen Datenformaten auf den hoheren Protokollschichten (ISO/OSI Schicht 6 und 7) ginge und nicht 
gleichzeitig auch um diffiziles Zeitverhalten auf den unteren Protokollschichten (ISO/OSI-Schichten 4 und darunter). 
Dort jedoch, wo sich Industrieprotokolle fiber mehrere Protokollschichten erstrecken, resultiert oft eine "Alles-oder- 
nichts "-Situation, in der die Office- Anwendung Daten mit dem industriellen Peripheriegerat nur fiber ein komplexes 
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Gateway austauschen kann. 

Ein Ansatz zur Losung dieses Problems besteht in der Verwendung von definierten Softwareschnittstellen (APIs, = 
Application Program Interface, Softwareschnittstelle zwischen Anwendungsprogramm und systemnaheri Softwaremo- 
duleh). Hierein fallen zatikeiche Softwareprodukte zum Zugriff auf Peripheriegerate uber nicht standardisierte APIs, 
DDE-Server und OPC-Server. Dem Problem inkompatibler Kommunikationsprotokolle wird hierbei durch Abstraktion 5 
von den konkreteh Datenubertragungsverfahren auf eine hohere Ebene - eine definierte Softwareschnittstelle zum An- 
wendungsprogramm - begegnet. Deshalb braucht eine Softwareanwendung nur Funktionen aus dem API aufrufen, um 
mit unterschiedlichen Peripheriegeraten Daten auszutauschen, ohne sich um die Details der Dateniibertragung zu kum- 
rhern. Ein API-basierender Ansatz - insbesondere, wenn er netzwerkfahig ist - ist an eine bestimmte Komponenten- 
bzw. Objekttechnologie wie OLE oder ActiveX gebunden. Er ist deshalb auch an bestimmte Betriebssysteme gebunden, to 
die die betreffende Komponententechnologie.unterstiitzen. Eine weitere Einschrankung dieses Ansatzes ist die impli- 
zierte Client/Server- Architektur von OPC und DDE, die davon ausgeht, dass ein zentraler Softwareprozess (der Server) 
mit unterschiedlichen Peripheriegeraten per Feldbus oder seriellen Punkt-zu-Punkt-Verbindungen verbunden ist. 

Ein fur OPC spezifisches Problem ist seine Komplexitat, sowohl im Hinblick auf die Einarbeitung als auch auf die Im- 
plementierung. OPC und OLE sind nur mit erheblichem Ressourceneinsatz im Feldgerat zu implementieren. Die Imple- 15 
mentierung eines OPC Servers in einem embedded System mit marktgangigen ftftikrocontrollern ist schwierig, wenn 
nicht unmoglich. 

Ein anderer Ansatz basiert auf dem Grundgedanken, mit Ethernet und TCP/IP ein durchgangiges Transportmedium fur 
die Dateniibertragung zu verwenden. Hier finden sich die unterschiedlichen Bestrebungen, die Ethernet als "Feldbus-Er- 
satz" propagieren und TCP als das kunftige universelle Transportprotokoll fur den Zugriff auf Automatisierungskompo- 20 
nenten. Ein grundlegendes Problem dieses Ansatzes ist, dass TCP lediglich ein Transportprotokoll (jedoch kein Anwen- 
dungsprotokoll) ist und aufgrund seines hohen Protokoll-Overheads nicht einmal besonders gut fur automatisierungs- 
technische Zwecke geeignet ist (geringer Datendurchsatz und langsamer VerbindungsaufbauZ-abbau). Augserdem ist 
TCP nicht paketorientiert, sondern datenstromorientiert. Bei datenstromorientierten (auch: zeichenorientierten) Proto- 
kollen kann eine einzelne Datenstruktur in mehrere Pakete unterschiedlicher Lange aufgeteilt werden, wobei dann der 25 
Empfanger der Daten das Problem hat, Anfang und Ende der Datenstruktur zu erkennen. Hierzu ist mindestens ein wei- 
teres hoherrangiges, paketoriehtiertes Protokoll erforderlich, fur das sich jedoch weder in der Automatisierungstechnik 
noch in der Office- Welt bisher ein Standard diirchgesetzt hat (Ansatze beinhalten zum Beispiel RFC 1006 und Modbiis/ 
TCP). In der Praxis sind derartige. nicht standardisierte Protokolle oberhalb von TCP nur durch OPC-Server oder ver- 
gleichbare API-Losungen zu verwenden. Dies ist ein grundlegender Unterschied zum Internet: Internet- Anwendungen 30 ? 
erfordern nicht die Verwendung eines bestimmten APIs oder einer bestimmten Komponententechnologie, um Email zu ; * 
versenden oder Webseiten abzurufen. Der Unterschied ist darin begrundet, dass Internet- An wendungen wbhldefinierte, \ 
einfache und leicht zu implementierende Anwendungsprotokolle verwenden, welche in der Fabrikautomation gerade 
fehlen. Ausserdem erfordert die Umstellung einer vorhandenen Kommumkationsmn^truktur mit gangigen Feldbussen 3 
und Punkt-zu-Punkt-Verbindungen auf Ethernet erhebliche Investitionen bei Hardware, Software, Training, Inbetrieb- 35 ? 
nahme und Wartung. 7 5 

Ein weiteres Verfahren besteht in der Integration eines Web-Servers ins Feldgerat (oft auf Basis eines in das Feldgerat f 
integrierten Industrie-PCs), wodurch das Feldgerat "Internet-fahig" wird. Dieses Verfahren ist allerdings nicht nur sehr 
kostspielig, sondern hat auch den Nachteil, dass das hierbei verwendete HTML-Dokumentenformat schlecht fur die au- 
tomatisierte Weiterverarbeitung durch einen Softwareprozess geeignet ist. 40 5 

Das alteste Verfahren zum softwaretechnischen Zugriff auf Automatisierungskomponenten besteht in Geratetreibem, 
die ein bestimmtes Industrieprotokoll implementieren. Der Geratetreiber kann vom Anwendungsprogramm uber eine 
proprietare Softwareschnittstelle (API) benutzt werden. Die Anwendung selbst braucht wenig oder gar nichts iiber das 
verwendete Protokoll zu wissen. Diese Vorgehensweise wurde vorrangig unter DQS verwendet, findet sich aber auch auf 
Windows- und Unix-Systemen. Die Implementierung des Geratetreibers erfolgt meist in Form einer statischen oder dy- 45 
namischen Softwarebibliothek (LIB bzw. DLL) oder in Form von Softwarekomponenten (ActiveX, VCL). Es gibt je- 
doch keinen API-Standard fur den Zugriff auf Automatisierungskomponenten. Ein Anwendungsprogrammierer, der un- 
terschiedliche Industrieprotokolle verwendet (um unterschiedliche Gerate anzusprechen), muss meist mehrere unter- 
schiedliche APIs verwenden. Des weiteren konnen Geratetreiber aus praktischer Sicht hormalerweise nur von Softwa- 
reentwicklern innerhalb selbst programmierter Anwendungen genutzt werden. Die Verwendung mit vorhandenen Stan- 50 
dard-Softwarean wendungen (wie zum Beispiel Web-Browsern) oder durch Nicht-Programmierer ist praktisch nicht 
moglich. Dariiber hinaus ist dieser Ansatz nur bedingt netzwerkfahig. Ein API oder Treiber impliziert eine eins-zu-eins- 
Verbindung zwischen einer Anwendung und einem Treiber bzw. einer DLL. In herkommlichen Softwarearchitekturen 
funktionieren solche Verbindungen nur lokal, nicht aber iiber das Netzwerk. Das bedeutet, dass der Treiber oder die DLL 
auf demselben Rechner laufen muss wie die Anwendung und die Automatisierungskomponente ebenfalls direkt an die- 55 
sem Rechner angeschlossen sein muss. Obwohl einige neuere APIs und Komponententechnologien (hauptsachlich 
DCOM und CORBA) in der Lage sind, "entfemte" oder "verteilte" Funktionen und Prozesse iiber das Netzwerk aufzu- 
rufen, geschieht dies um den Preis erhohter Komplexitat und proprietarer Technologie (im Fall von DCOM). Die grosse 
Mehrzahl verfugbarer APIs bzw. Treiberschnittstellen (implementiert als DLL oder als DDE-Server) im Bereich der Fa- 
brikautomation ist nicht netzwerfahig; weshalb die Softwareanwendung auf derselben Maschine laufen muss, an den die 60 
Automatisierungskomponente direkt angeschlossen ist. Dies nachteilig, da Anwendungen (speziell auf den hoheren Ebe- 
nen der Automatisierungspyramide) eher zur Zentralisierung tendieren, wogegen Automatisierungskomponenten und 
Steuerungen eher zur Dezentralisierung tendieren. , 

DDE (Dynamic Data Exchange) ist ein Verfahren zur Interprozesskommunikation, mit dem Windows- Programme un- 
tereinander Nachrichten austauschen konnen. Windows-Systemaufrufe konnen dazu benutzt werden, um Nachrichten an 65 
eine andere Anwendung zu senden oder Nachrichten yon einer anderen Anwendung zu empfangen. Viele Softwarehau- 
ser bieten DDE-Server fiir Industrieprotokolle an. Oftmals ermoglichen es solche DDE-Server Windows- Anwendungen, 
Daten mit Automatisierungskomponenten auszutauschen, ohne Details iiber die verwendeten Ubertragungsprotokolle 
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und -medien zu kennen.,Das Problem inkompatibler Protokolle und Datenformate wird durch ein ubergeordnetes API 
umgangen, welches die Details der Dateniibertragung vor der Anwendung verbirgt. DDE-Server verwenden ein einheit- 

' liches API (das Windows DDE API), welches auch von zahlreichen vorhandenen Windows-Anwendungen (z. B. Micro- 
soft Excel) unterstutzt wird. Deshalb konnen DDE-Server auch von Nicht-Programmierern benutzt werden. Andererseits 
5 erfordert DDE das Betriebssystem Microsoft Windows und ist nicht netzwerkfahig. Ausserdem hat DDE eine sehr ge- 
ringe Performance und einen hohen Overhead. 

OPC ist eine Weiterentwicklung der DDE-Server-Technologie fur das industrielle Umfeld auf der Basis von OLE (Ob- 
ject Linking and Embedding). OLE ermoglicht es Windows-Anwendungen, untereinander Daten ("Objekte") auszutau- 
schen, selbst per Netzwerk. Die Architektur von OPC ist nahezu identisch mit DDE, mit dem Unterschied, dass ein OPC- 

10 Server auch auf einem anderen, per TCP/IP-Netzwerk erreichbarem Rechner installiert werden kann. OPC Client und 
Server laufen jedoch stets auf PCs mit dem Betriebssystem Microsoft Windows. OPC ist eine komplexe Prograrnmier- 
schnittstelle mit hohem Einarbeitungs auf wand. 

Seit kurzem nehmen die Bestrebungen zu, Ethernet als "besseren Feldbus" oder "Feldbus-Ersatz" in der Indus trieau- 
tomation einzusetzen. Dies aufgrund der.Tatsache, dass Ethernet das dominierende tjbertragungsmedium im Bereich der 

15 Burokommunikation ist, und Bauteile zu giinstigen Preisen von einer Vielzahl von Anbietem bezogen werden konnen. 
Ausserdem unterstutzt Ethernet hohere'Ln^ertragungsgeschwindigkeiten als konventionelle Feldbusse und ermoglicht ei- 
nen einfachen Internet-Zugang. 

Die Ludwigsburger Firma Jetter AG hat daraufhin ein neues Steuerungskonzept entwickelt, welches Ethernet und 
TCP/IP fur den Datenaustausch im gesamten Unternehmen verwendet, bis hin zum Feldgerat in der.Produktionsstatte. 

20 Dieses Konzept erfordert allerdings den Austausch vorhandener Maschinen und Automatisierungskomponenten, die 
nicht uber eine Ethernet-Schnitts telle verfugen. Das resultierende Netzwerk wird durch Switches und Hochgeschwindig- 
keits-Ethemet nahezu echtzeitfahig, obwohl Ethernet streng genommen aufgrund seiner nichtdeterministischen Proto- 
kollarchitektur nicht fur Echtzeitanwendungen geeignet ist. Wahrend Industrieautomation normalerweise in Form einer 
hierarchischen Architektur dargestellt wird ("Automatisierungspyramide"), ist das Jetter-Modell flach und ohne unter- 

25 schiedliche hierarchische Ebenen. Es gibt keine isolierten Automatisierungszellen mehr, da die Steuerung zentral vorge- 
nommen wird und nicht dezentral von SPSen. Die zur Steuerung verwendete Software lauft nicht auf einer lokalen SPS, 
sondem auf einem Server im Netzwerk. Einschrankungen dieses Losungsansatzes sind: Vorhandene Steuerungs- und 
Kommunikationshardware muss ersetzt werden durch die Hardware eines einzigen Herstellers; ein Standard- An wen- 
dungsprotokoll (ISO/OSI-Schicht 7) wird nicht spezifiziert, so dass die Anwendungsschicht proprietor ist; somit gibt es 

30 auch nur proprietare, nicht standardisierte Ubergange in die kaufmannische Datenverarbeitung. 

ZUSAMMENFASSUNG DER ERFINDUNG 

Die vorliegende Erfindung vermeidet die dargestellten Nachteile des gegenwartigen Stands der Technik mithilfe eines 

35 Systems und Verfahrens zum automatisierten Datenaustausch zwischen Steuerungsebene und Planungsebene. Dabei be- 
ll alt die vorliegende Erfindung das hierarchische Modell der Fabrikautomation ("Automatisierungspyramide"), welches 
sich in vielen tausend Install ationen bewahrt hat, beL Ausserdem passen Implementierungen der vorliegenden Erfindung 
zu vorhandenen standardisierten Softwareschnittstellen. Implementierungen der vorliegenden Erfindung konnen auf 
zahlreichen Betriebssystemen und in Feldgeraten vorgenommen werden, ohne dass dafur die Ressourcen eines Wind- 

40 ows-PCs erforderlich sind. Des weiteren kann die vorliegende Erfindung unter Benutzung unterschiedlicher Ubertra- 
gungsmedien und -protokolle implementiert werden. 

In bestimmter Hinsicht kann die vorliegende Erfindung ein System zur Verteilung von Automatisierungsdaten (Auto- 
mation Data Distribution, abgekiirzt ADD) verkorpern, bestehend aus einer datenverarbeitenden Station (DS) mit einer 
Netzwerkadresse, und einer Automatisierungskomponente (AK) mit einer Netzwerkadresse, funktional an die DS ge- 

45 koppelt; wobei DS und AK so konfiguriert sind, dass sie miteinander durch Verwendung eine oder mehrere Transaktio- 
nen kbmmunizieren, wobei besagte Transaktion aus einem Datagramm besteht, welches vollstandig und in Klarschrift 
codiert ist. In dieser Implementierung konnen die Datagramme desweiteren ein Quell- Attribut enthalten, welches die 
Netzwerkadresse des Absenders des Datagramms angibt, ein Ziel- Attribut, welches die Netzwerkadresse des intendier- 
ten Empfangers dieses Datagramms enthalt, und/oder ein Wert- Attribut mit einem korrespondierenden Einheits- Attribut, 

50 welches die Masseinheit des Wert-Attributs angibt. Dariiber hinaus konnen Datagramme ein oder mehrere Sicherheitsat- 
tribute enthalten (einschliesslich, jedoch nicht beschrankt auf ein Attribut fur eine digitale Signatur und/oder ein Attribut 
fur ein Gultigkeitsende oder "Verfallsdatum ,, ), ein Zeitstempel- Attribut, und/oder ein oder mehrere Fehlersicherungs- At- 
tribute (einschliesslich, jedoch nicht beschrankt auf ein Prufsummen- Attribut, welches Redundanzinformationen des Da- 
tagramm-Inhalts enthalt, und ein Sequenznummer- Attribut). Das ADD-System kann dariiber hinaus Profile enthalten, 

55 welche den Aufbau von einem oder mehreren Datagrammen spezifizieren. Solche Profile konnen die Konfiguration von 
mindestens einem besagter Datagramme fur die Benutzung mit einer bestirnmten AK spezifizieren. Das oder die Datag- 
ramme konnen so gestaltet sein, dass ein Zustand der AK reprasentiert wird. Das oder die Datagramme konnen so gestal- 
tet sein, dass ein Kommando vori einer DS an eine AK reprasentiert wird. Das oder die Datagramme konnen dafur be- 
nutzt werden, den Empfang eines vorherigen Datagramms zu quittieren. Die Transaktionen konnen aktiv, passiv, oder 

60 eine Kombination von aktiv und passiv sein. Optional kann das ADD-System eine Koordinierungss telle beinhalten, wel- 
che funktional mit den DS und AK gekoppelt ist und welche den DS und AK Netzwerkadressen zuweisen kann. In eini- 
gen Implementierungen konnen die Datagramme das FactoryXML-Format verwenden. In anderen Implementierungen 
konnen die Klarschriftbeschreibungen das UTV-Format verwenden. 

In anderer Hinsicht kann die vorliegende Erfindung ein System zur Verteilung von Automatisierungsdaten darstellen, 

65 welche eine Planungsebene mit einem Planungs-Netzwerk umfasst, an das eine oder mehrere DS angeschlossen sind; 
eine Steuerungsebene mit einem Steuerungs-Netzwerk, an das ein oder mehrere AK angeschlossen sind; und ein oder 
mehrere Gateways, die funktional mit der oder den AK und mit dem Planungsnetzwerk gekoppelt sind, wobei das oder 
die Gateways dazu dienen, der oder den DS die Kommunikation mit der oder den AK zu erleichtern, indem sie ein oder 
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mehrere Datagramme erzeugen und an besagte AK schicken; und in dem die AK so arbeiten kann bzw. konnen, dass sie 
mit der oder den DS dadurch kommunizieren, dass sie eine oder mehrere batagramme durch das oder die Gateways an 
die DS generieren und senden. 

In anderer Hinsicht kann die vorliegende Erfindung ein Datagramrn umfassen, welches innerhalb eines Systems zur 
Verteilung von Automatisierungsdaten verwendet wird, welches wiederum aus mindestens einer AK besteht, die funk- 5 
tional mit mindestens einer Zielkomponente gekoppelt ist, wobei wobei das Datagramrn aus einem Quell-Attribut be- 
steht, das die Quelle (den Absender) des Datagramms kennzeichnet, einem Ziel-Attribut, welches das Ziel (den Empfan- 
. ger) des Datagramms kennzeichnet, wobei das Ziel eine DS oder eine AK sein kann, und das Datagramrn yollstandig co- 
diert ist. , 

In wiederum anderer Hinsicht kann die vorliegende Erfindung ein Verfahren zur Verteilung von Automatisierungsda- lb 
ten beinhalten in einem System, welches aus einer DS besteht, die funktional mit einer AK gekoppelt ist, wobei das Ver- 
fahren eine. Quelleinheit beinhaltet, die ein Datagramrn generiert, welches aus vollstandig codierten Beschreibungen in 
Klarschrift besteht, und einer Zieleinheit, welche das Datagramrn empfangt und darauf in geeigneter Weise reagiert. In 
dieser Implementierung kann die Quelleinheit eine DS sein, die ein Abfrage-Datagramm an die Zieleinheit (eine AK) 
sendet, und die Zieleinheit dadurch antwortet, dass sie ein Antwort-Datagramm an die Quelleinheit schickt, wobei das 15 
Antwort-Datagramm aus einem Wert-Attribut und einem zugehorigen Attribut mit der verwendeten Masseinheit besteht. 
Weiterhin kann das Verfahren in dieser Implementierung eine Quelleinheit (eine AK) beinhalten, die aktiv beim Eintre- 
ten vordefinierter auslosender Ereignisse ein oder mehrere Datagramme erzeugt und das oder die Datagramme an die 
Zieleinheit sendet. 

In der vorliegenden Patentschrift bedeutet der Begriff Vein" "ein oder mehrere". 20 

KURZBESCHREIBUNG DER ZEICHNUNGEN 

Die folgenden Zeichnungen sind Bestandteil der vorliegenden Patentanmeldung und sind beigefugt, um bestimmte 
Aspekte der vorliegenden Erfindung zu veranschaulichen. Durch den Verweis auf eine oder mehrere der Zeichnungen in 25 
Verbindung mit der detaillierten Beschreibung spezifischer Implementierungen, wie sie hier dargestellt werden, ist die 
Erfindung eventuell besser zu verstehen. 

Fig. 1 ist ein abstraktes Blockdiagramm. einer beispielhaften Implementierung der vorliegenden Erfindung, welches 
ein System zur Verteilung von Automatisierungsdaten veranschaulicht. 

Fig. 2 ist ein abstraktes Blockdiagramm einer beispielhaften Implementierung der vorliegenden Erfindung und veran- 30 
schaulicht ein alternatives System zur Verteilung von Automatisierungsdaten, welches ein Hardware-Gateway beinhal- 
tet. 4 

Fig. 3 ist ein abstraktes Blockdiagramm einer beispielhaften Implementierung der vorliegenden Erfindung und veran- 
schaulicht ein alternatives System zur Verteilung von Automatisierungsdaten, welches ein DDE-Software-Gateway be- 
inhaltet. 1 ' 35 

Fig. 4 ist ein abstraktes Blockdiagramm einer beispielhaften Implementierung der vorliegenden Erfindung und veran- 
schaulicht eiri alternatives System zur Verteilung von Automatisierungsdaten, welches ein OPC-Software r Gateway be- 
inhaltet. * . 

BESCHREIBUNG B EIS PIELH AFTER IMPLEMENTIERUNGEN : 4 o 

Fig. 1 zeigt ein System zur Verteilung von Automatisierungsdaten ("ADD") entsprechend einer beispielhaften Imple- 
mentierung der vorliegenden Erfindung. Ein Vorteil der vorliegenden Erfindung besteht darin, dass sie den Datenfluss 
zwischen und innerhalb der Steuerungsebene (160) und der Planungsebene (150) eines geschlossenen Systems wie einer 
Fabrik oder eines Biiros erleichtert. Kaufmannische Softwareanwendungen auf Computern befinden sieh normalerweise 45 
innerhalb der Planungsebene (150), wahrend sich speicherprogrammierbare Steuerungen, Peripheriegerate, Feldgerate 
und automatisierungstechnische Softwareanwendungen normalerweise innerhalb der Steuerungsebene befinden. Fur die 
Zwecke der vorliegenden Schrift wird die Bezeichnung "datenverarbeitende Station" (DS) fur steuernde, uberwachende 
und auswertende Gerate und Softwareanwendungen sowohl in der Steuerungsebene als auch in der Planungsebene ver- 
wendet. Der Begriff "Automatisierungskomponente" (AK) bezieht sich hingegen auf Peripheriegerate, Feldgerate und 50 
automatisierungstechnische Softwareanwendungen. Systemkomponenten (sowohl AK als auch DS) konnen physikali- 
sche Gerate sein, Peripheriegerate und Softwareanwendungen. 

Die vorliegende Erfindung ermoglicht wirkliche Datenverteilung innerhalb des Gesamtsystems durch die Verwendung 
eines einheitlichen Transaktions-Formats, das von alien Systemkomponenten verwendet wird, egal auf welcher Ebene 
sie sich befinden. Die Transaktions-Grundeinheit fiir Dateniibertragung in ADD ist ein vollstandig codierter Geratezu- 55 
stand oder ein vollstandig codiertes Kommando. Vollstandig codiert bedeutet, dass keine zusatzliche Information (wie 
eine vordefinierte Umsetzungstabelle) erforderlich ist, um den Geratezustand oder das Kommando zu bestimmen. Im 
Gegensatz hierzu liefern gangige AK oft nur einen einzelnen Wert, wenn sie abgefragt werden. Zum Beispiel kann eine 
gangige Waage ihre Daten fiber ihre Computerschnittstelle einfach mit einer Zeilenbegrenzung versehen abliefem (z B 
525.55[CR]). Obwohl 525.55 auf eine Gewichtsmessung hinweisen kann, musste eine DS noch wis sen, welche Massein- 60 
heit die betrefifende Waage verwendet hat. In einer typischen Installation wiirde die DS "wissen" (vielleicht durch Her- 
anziehung einer Umsetzungstabelle), dass die Daten von einer bestimmten AK (zum Beispiel "Waage 3") in Kilogramm 
kalibriert sind. Ohne Kenntnis der verwendeten Masseinheit sind Daten von AK von begrenztem Wert. Selbst bei Ver- 
wendung von Umsetzungstabellen ist diese Art der Implementierung schlecht geeignet fur eine Verteilung der Daten in- 
nerhalb eines Netzwerks, da eine beliebige DS innerhalb des Netzwerks nicht in der Lage ware, die Datenquelle, den 65 
Zeitpunkt und die Masseinheit der Messung zu bestimmen. Ausserdem waren bei Konfigurationsanderungen netzwerk- 
weite Updates der Umsetzungstabellen erforderlich. ADD begegnet diesem Problem durch die \erwendung von voll- 
standig codierten Geratezustanden oder Kommandos, welche im vorangegangenen Beispiel die Masseinheit des ubertra- 



5 



* 4. 



DE 101 12 843 A 1 . 

genen Wertes beinhalten wiirden. 

Ein vollstandig codierter Datensatz sollte einer DS wenigstens ermoglichen, ohne Zugriff auf externe Information die 
Datenquelle zu ermitteln und, falls Daten ubertragen werden, die Einheit dieser Daten. Bei vollstandiger Codierung sind 
Umsetzungstabellen beim Empfanger nicht notig. Die ubermittelte Information sollte von beliebigen Empfangern ohne 
5 weitere Anforderungen verarbeitet werden konnen. 

In bevorzugten Implementierungen verwendet die vorliegende Erfindung Datensatze in Klartext, wann immer mog- 
lich und sinnvoll. Die Codierung von Daten in Klarschrift hat mehrere Vorteile gegenuber anderen Codierungsarten. Er- 
stens ist sie menschlich lesbar. Das allereinfachste "Terminal" (das heisst, ein Dracker oder ein einfaches Datensichtge- 
rat) kann benutzt werden, um ADD-Dateri fur einen menschlichen Benutzer anzuzeigen. Viele altgediente Wartungsin- 

10 genieure im Aussendienst hat es viel Zeit und Frustration gekostet, gestorte Ubertragungskanale durch das Entziffern von 
Bitfeldern, Priifsummen usw. zu analysieren. Die Moglichkeiten zur Fehlersuche sind bei ADD hervorragend, was wich- 
tig fur die Falle ist, in denen aufwendige Datentester normalerweise nicht zur Verfugung stehen und Ausfallzeiten teuer 
sind. Mit ADD kann ein Wartungsingenieur ein Gerat sogar mit einem einfachen Terminal-Emulator manipulieren, da 
ADD-Datensatze ohne aufwendige Software zusammengestellt und ubertragen werden konnen. 

15 Desweiteren ist die von ADD verwendete Klarschrift-Codierung weniger fehleranfallig fur Versionskonflikte inner- 
halb einer verteilten Umgebung. Bei Binarcodierung mussen Umsetzungstabellen verwendet werden, um die iibertrage- 
nen Daten zu interpretieren. Wenn die Umsetzungstabellen lokal gespeichert werden (wie dies normalerweise der Fall 
ist), treten Fehler auf, wenn diese Tabellen nicht im gesamten Netzwerk upgedated werden. Ein Vorteil von ADD liegt 
darin, dass die Notwendigkeit von Umsetzungstabellen zur Interpretation von Daten weitgehend schwindet. 

20 Weiterhin stellt die Verwendung von Klarschrift-Codierung wenig Anspriiche an den Ubertragungskanal. In einigen 
Implementierungen der vorliegenden Erfindung kann eine 7-Bit-Codierung verwendet werden, und ASCII-Steuerzei- 
chen konnen f Or Protokollzwecke verwendet werden, wenn sie nicht in den Nutzdaten auf treten. Diese Implementierun- 
gen vereinfachen die Konstruktion von Gateways. Die vereinfachte Datenformatierung vereinfacht die Verteilung der 
Daten bedeutend. 

25 Wie gezeigt kann eine Implementierung der vorliegenden Erfindung ein oder mehrere DS (kaufmannische Software- 
anwendung [100] und speicherprogrammierbare Steuerung / SPS [110]) und eine oder mehrere AK (120 und 130) bein- 
halten, welche funktional durch ein Ubertragungsmedium (140) miteinander gekoppelt sind. Obwohl DS 100 und 110 
und AK 120 und 130 als direkt an das Ubertragungsmedium angeschlossen dargestellt sind, wird ein technisch kundiger 
Leser verstehen, dass "funktional gekoppelt" keine direkte Verbindung erfordert Fur die Zwecke der vorliegenden Pa- 

30 tentschrift kann ein Gerat als funktional gekoppelt mit einem anderen Gerat bezeichnet werden, wenn die Gerate mitein- 
ander Informationen austauschen konnen, unabhangig vom Vorhandensein irgendwelcher zwischengeschalteter Gerate 
oder Ubertragungsmedien. 

In einer bevorzugten Implementierung kann ADD direkt in jede AK implementiert werden. Dadurch konnten AK 120 
und 130 direkt mit DS 100 und 110 kommunizieren. Diese Implementierung ware geeignet, traditionelle Industrieproto- 
35 kolle wie zeilenorientiertes ASCII, Modbus oder das AK-Protokoll (ein Anwendungsprotokoll aus der Automobil-Zulie- 
ferindustrie) zu ersetzen. TCP/IP uber Ethernet ist ein bevorzugtes Ubertragungsmedium 140. Ein technisch kundiger 
Leser wird indessen verstehen, dass jedes geeignete Ubertragungsmedium 140 verwendet werden kann, einschliesslich 
(jedoch nicht beschrankt auf) serielle Asynchronverbindungen, ISDN, drahtloses TCP/IP, USB, Verbindungen uber Par- 
allelschnittstellen und GSM. 

40 In einigen Fallen mdgen Systemkomponenten der Steuerungsebene (160) nicht in der Lage sein, die erforderlichen 
Netzwerkprotokolle zur direkten Kommunikation mit Systemkomponenten auf der Planungsebene (160) zu benutzen 
oder sich daran anzuschliessen. In diesen Fallen kann ein Gateway benutzt werden, um eine Kommunikation zu ermog- 
lichen. Viele der heute gebrauchlichen Gateways (sowohl Hardware- als auch Softwaregateways) konnen hierfur benutzt 
werden. Ein technisch kundiger Leser konnte angeben, welches spezielle Gateway mit den Systemkomponenten in einer 

45 bestimmten Implmentierung benutzt werden kann. 

Wie in Fig. 2 dargestellt, konnen ADD-Hardware-Gateways (210, 220, 230) benutzt werden, wo vorhandene AK nicht 
in der Lage sind, die erforderlichen Netzwerkprotokolle zu benutzen oder sich daran anzuschliessen. Ein ADD-Hard- 
ware-Gateway ubersetzt vom Netzwerk-Medium zum Punkt-zu-Punkt-Medium (beispielsweise serielle Asynchron- 
schnittstelle) und kummert sich um die erforderlichen Protokollumwandlungen auf den hoheren Schichten (wie zumBei- 

50 spiel der Prasentationsschicht und der Anwendungsschicht). ADD erfordert im allgemeinen keine grosse Rechen- und 
Speicherkapazitat. ADD-Hardware-Gateways konnen daher in bevorzugten Implementierungen as kleine Protokollkon- 
verter implementiert werden, die hutschienenmontiert oder als Zwischenstecker auf eine vorhandene Kommunikations- 
schnittstelle der AK aufgesteckt werden konnen. Ein Beispiel fur ein ADD-Hardware-Gateway ist (ohne hierauf be- 
schrankt zu sein) ein SMS-Gateway. 

55 In anderen (nicht abgebildeten) Implementierungen der vorliegenden Erfindung kann das Ubertragungsmedium 140 
aus zwei Netzwerken bestehen, einem Netzwerk der Steuerungsebene und einem Netzwerk der Planungsebene, mit ei- 
nem oder mehreren Hardware-Gateways zur Erleichterung der Kommunikation zwischen den beiden Ebenen. Das Pla- 
nungsnetzwerk und das Steuerungsnetzwerk konnen beide als Teile des Gesamtnetzwerks 140 betrachtet werden. In an- 
deren Implementierungen mogen die AK 120 und 130 tiberhaupt nicht direkt mit dem Ubertragungsmedium 140 verbun- 

60 den sein. In diesen Implementierungen konnen die AK 120 und 130 stattdessen mit einer SPS 110 verbunden sein, wel- 
che ihrerseits an das Ubertragungsmedium 140. uber ein Hardware- oder Software-Gateway (siehe unten) gekoppelt ist. 

Alternativ kann die Gateway-Funktionalitat auch softwaremassig implementiert werden. Wie in Fig. 3 dargestellt, 
kann ein ADD-Softwaregateway als DDE Client 300 implementiert werden, der mit AK 340 uber einen DDE Server 320 
kommuniziert. Wie dargestellt, kann das ADD Gateway auf dem Computer installiert werden, auf dem der DDE Server 

65 lauft. DDE-Implementierungen laufen gegenwartig ausschliesslich auf Windows-PCs. Da die meisten Windows-PCs 
netzwerkfahig sind, hat diese Implementierung den zusatzlichen Vorteil, dass ADD-Systemkomponenten im gesamten 
Netzwerk den DDE Server benutzen und mit ihm kommunizieren konnen. Der DDE Server 320 kann mit einer AK 340 
uber ein Indus trieprotokoll 330 kommunizieren und dieses in DDE API-Aufrufe 310 fur die Kommunikation mit dem 
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• v 

DDE Client 300 ubersetzen, und umgekehrt. 

Wie in Fig. 4 gezeigt, kann ein ADD Softwaregateway auch als OPC Software-Gateway implementiert werden. Im 
speziellen kann ein ADD Gateway als OPC Client-Anwendung 400 implementiert werden. In der abgebildeten Imple- 
mentierung meldet sich das ADD Gateway als OPC Client bei einem OPC Server 430 an und setzt ADD in OPC 400 und ' 
umgekehrt urn, um mit AK 450 zu kommunizieren. Ein Vorteil hiervon ist, dass vorhandene OPC Client-Software 410 5 
weiter benutzt werden kann, da OPC Server mehrere Clients gleichzeitig bedienen konnen. 

Eine dritte Gruppe von Gateway-Software (ohne Abbildung) unterstutzt jene Industrieprotokolle, die von sich aus 
TCP/IP als Ubertragungskanal verwenden, wie RFC 1006, oder die Netzwerkvariante von Modbus, oder Peripheriege- 
rate wie digitale I/O-Baugruppen mit proprietaren Netzwerkprotokollen. Diese Art ADD-Gateway kann auf irgendeinem 
Computer im Netzwerkinstalliert werden. Eine DS wiirde in diesem Fall nicht direkt mit der Systemkompdnente "hin- 10 
ter" dem Gateway kommunizieren. Stattdessen wiirde die DS ein Datagramm an die Netzwerkadresse des Gateways 
schicken. Das Gateway iibersetzt das Datagramm in die ProtokoUe und Kommandos der Systemkbmponente und umge- 
kehrt. . 

In anderen Implementierungen (ohne Abbildung) kann eine Kombination aus Software- und Hardware-Gateways in- 
nerhalb desselben Systems verwendet werden. Desweiteren konnen einige Implementierungen der vorliegenden Erfin- 15 
dung Gateways fur Systemkomponenten verwenden, die Gateways erfordern, und zusatzlich andere Systemkomponen- 
ten, die ADD-kornpatibel sind und keine Gateways erfordem. 

Transaktionen 

. 20 

In ADD-Systemen erfolgt die Kommunikation zwischen AK und DS (und untereinander) durch eine oder mehrere 
Transaktionen. Allgemein gesprochen sind Transaktionen ein Informationsaustausch zwischen verschiedenen System- 
komponenten des ADD-Sy stems in Form vollstandig codierter Datagramme. Fiir Zwecke der vorliegenden Patentschrift 
bestehen alle Datagramme aus vollstandig codierter Information. In einigen Fallen kann der Inhalt eines Datagramms 
Daten in einem Format enthalten, das nicht ohne weiteres menschlich lesbar ist (zum Beispiel binar oder hexadezimal co- 25 
dierte Daten). Bevorzugterweise sind Datagramme jedoch menschlich lesbar, wenn immer es moglich ist. 

Vollstandig codierte Datagramme sind die Basiseinheit einer ADD-Transaktion. Ein Datagramm kann mit einem "Re- 
cord" (Datensatz) einer Datenbank verglichen werden. Ein Datagramm kann unterschiedliche Funktionen haben. TVpi- 
sche Funktionen sind (ohne hierauf beschrankt zu sein): Darstellung eines Geratezustands, Darstellung eines Komman- 
dos, oder Quittierung eines vorangegangenen Kommandos. In einigen Fallen kann ein Datagramm mehrere Funktionen 3(T J 
gleichzeitig haben. * ^ 

Im Hinblick auf AK konnen Transaktionen in die beiden Kategorien "aktiv" und "passiv" unterteilt werden. Bei pas- 
siven Transaktionen empfangt eine AK ein Kommando oder eine Anfrage von einer anderen Systemkomponente und 
kann darauf, falls erforderlich, entsprechend antworten. Bei aktiven Transaktionen kann eine AK Daten spontan, auf ei- * 
gene Initiative hin iibertragen (normalerweise beim Eintreten eines auslosenden Ereignisses, oder zyklisch). In vielen "35 
Systemen sind aktive Transaktionen zu bevorzugen, da sie den Trend zur Dezentralisierung verstarken - sie reduzieren "tt 
den Datenverkehr im Netz und vereinfachen die Programmierung von datenverarbeitenden Anwendungen, dem ereignis- , '7 1 
gesteuerten Paradigma der modemen Softwareentwicklung entsprechen, wie es fur IT-Anwendungen iiblich ist. Die spe- c 
zifische Struktur und Konfiguration jeder Transaktion kann von mehreren Faktoren abhangig sein, inklusive (jedoch 
ohne hierauf beschrankt zu sein) der Art der Implementierung, dem Datenformat (siehe unten) und den Ubertragungska- 40 
nalen, die in einem ADD-Sy stem verwendet werden; 

Jedes Datenformat kann benutzt werden, das zu vollstandig codierten Datagrammen fuhrt. Dabei werden zwei Daten- 
formate - FactoryXML und UTV (Unstructured TagA^alue) bevorzugt, weil sie gut zu existierenden Softwareschnittstel- 
len passen. FactoryXML ist abgeleitet yom Format der extensible Markup Language (XML). UTV enthalt ahnliche In- 
halte wie FactoryXML, verwendet jedoch eine einfachere, unstrukturierte Syntax. 45 

FactoryXML 

FactoryXML benutzt die im XML-Standard definierte Syntax, entspricht aber nicht notwendigerweise dem XML-Do- 
kumentenmodell. Anstelle des fur XML-Dokumente typischen sfatischen Inhalts kann (und wird) sich der Inhalt eines 50 
FactoryXML-Datagramms, welches einen Geratezustand reprasentiert, dynamisch andern. Ausserdem konnen sich meh- 
rere FactoryXML-Datagramme auf ein und denselben Gegenstand beziehen. Dies ist ein wichtiger Unterschied zwischen 
XML und FactoryXML. In XML ist die Grundeinheit ein Dokument (oder eine Datei). Unterschiedliche Dokumente re- 
prasentieren unterschiedliche Dinge (Bucher, Artikel usw.). In FactoryXML ist die Grundeinheit ein Datagramm. Unter- 
schiedliche FactoryXML-Datagramme konnen sich auf ein und denselben Gegenstand beziehen (zum Beispiel auf ein 55 
bestimmtes Peripheriegerat), und reprasentieren dabei unterschiedliche Zustande zu unterschiedlichen Zeitpunkten. Ob- 
wohl sich der Zustand des Peripheriegerats andern kann, bleibt das Peripheriegerat doch ein und dasselbe. Da ein voll- 
standig codiertes ADD-Datagramm einen Geratezustand eindeutig reprasentieren muss, darf es innerhalb eines Facto- 
ryX^^-Datagramms keine mehrfachen identischen Unterelemente geben. Ein Sensor kann zum Beispiel zu einem be- 
stimmten Zeitpunkt immer nur einen bestimmten Wert liefern. Jede Anderung muss in einem separaten Datagramm co- 60 
diert werden. Ein Sensor-Datagramm mit mehrfachen "value"-Elementen ist daher unzulassig (wogegen mehrfache " va- 
lue"-Elemente wie "valuel", "value2 fK usw. bei komplexen Sensoren benutzt werden konnen, solange keine mehrfachen 
Instanzen eines einzelnen Elements existieren). Demgegenuber sind mehrfache Unterelemente in XML-Dokumenten 
(z. B. "Kapitel", "Absatz") zulassig und sogar iiblich. Trotz der Unterschiede zwischen XML und FactoryXML konnen 
FactoryXML-Datagramme von gewohnlichen XML-Parsern verarbeitet werden. Deshalb kann eine XML-fahige Daten- 65 
bank FactoryXML-Datagramme auch unmittelbar speichern. 

Ein beispielhaftes FactoryXML-Datagramm kann wie folgt aussehen: 
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<sensor src="Themometer2" t="l 81 234" 
seq = "42537" crc="5528' > > 
5 <value>45.755</value> 

<unit><Fahrenheit/><yunit> 
</sensor> 

10 

Implementierungen der vorliegenden Erfindung, welche Factory XML-Datagramme (wie das obige Beispiel) verwen- 
den, konnen aus einem oder mehreren Elementen bestehen, die einen Elementnamen ("Tag") urid einen optimalen Inhalt 
(Wert) haben. 

In einigen Implementierungen konnen Tags lediglich aus Buchstaben in Kleinschreibung bestehen, mit Ausnahme 
15 vordefinierter Tags, bei denen der erste Buchstabe gross geschrieben ist. Alternativ kann Gross- und Kleinschreibung 
ignoriert werden. 

Ein Factory XML-Element kann Unterelemente beliebiger hierarchischer Tiefe enthalten. Unterelemente des Facto- 
ryXML-Wurzelelements miissen jedoch eindeutig sein; mehrfache identische Unterelemente sind nicht erlaubt, egal, ob 
sie auf derselben oder auf unterschiedlichen hierarchischen Ebenen stehen. Tags fur Factory XML-Elemente konnen frei 

20 definiert werden, mit der Ausnahme vordefinierter Standard-Tags (siehe unten). 

FactoryXML beinhaltet eine standardisierte Attributliste. Welche Standardattribute in einem bestimmten Facto- 
ryXML-Datagramm verwendet werden, kann konfiguriert werden (zum Beispiel durch die Verwendung von Profilen, 
siehe unten). Die Standard- Attributliste kann folgende Attribute enthalten (ohne hierauf beschrankt sein zu miissen): At- 
tribute zur Datensicherheit (zum Beispiel eine digitale Signatur, ein Gultigkeitsende usw.), einen Zeitstempel, und Attri- 

25 bute zur Sicherung der Datenintegritat (zum Beispiel eine Prufsumme, CRC usw.). 

Obwohl FactoryXML- Attribute generell optional sind, kann ihfe Verwendung oder Nicht- Verwendung in bestimmten 
Situationen vorgeschrieben sein, die durch die Konfiguration des ADD-Systems spezifiziert werden. So kann zum Bei- 
spiel die Verwendung einer digitalen Signatur die gleichzeitige Verwendung eines Zeitstempels und einer Sequenznum- 
mer erfordern. Ein FactoryXML-kompatibles Gerat muss in der Lage sein, alle Standard- Attribute zu verarbeiten und 

30 darf nicht mit Fehlerzustanden oder undefiniertem Verhalten auf den Empfang irgendeines Standard-Attributs reagieren. 
In vielen FactoryXML-Implementierungen kann die Codierung von Datagrammen im ASCII-Zeichensatz erfolgen. 
Numerische Daten konnen als Fliesskommawerte mit einem Dezimalpunkt codiert werden, mit einem optionalen Vorzei- 
chen (Prafix) und einem optionalen Exponenten (Suffix). Ein weggelassenes Vorzeichen kann einen positiven Wert an- 
zeigen. Ein weggelassener Exponent kann einen Exponenten von eins anzeigen. Daten konnen auch als ganzzahlige 

35 Werte (Integer) dargestellt werden, entweder in dezimaler oder in hexadezimaler Schreibweise. Hexadezimale Schreib- 
weise kann durch den Prafix "Ox" angezeigt werden. Negative dezimale Werte konnen durch ein vorangestelltes Minus- 
zeichen kenntlich gemacht werden. Ein weggelassenes Vorzeichen kann einen positiven Wert kennzeichnen. Daten kon- 
nen auch als Textwerte dargestellt werden. Textwerte setzen sich aus Zeichenketten zusammen, wie sie im XML-Doku- 
mentenformat spezifiziert sind. Die Verarbeitung von Textzwischenraumen (Whitespace) kann identisch zum XML-Do- 

40 kumentenformat erfolgen. Schliesslich kann FactoryXML einen Satz vordefinierter Tags zur eindeutigen Kennzeichnung 
bestimmter Zustande und Einheiten bereitstellen. Vordefinierte Tags konnen in FactoryXML-Datagrammen als leere Ele- 
mente verwendet werden. Der Anfangsbuchstabe eines vordefinierten Tags ist immer gross geschrieben. Beispiele um- 
fassen (ohne Anspruch auf Vollstandigkeit): <On/>, <OfT/>, <Leftl>, <Right/>, <Up/>, <Down/>, <Open/>, <Closed/>, 
<Full/>, <Empty/>. Die Verwendung dieser Tags kann ohne die Angabe einer Einheit erfolgen. Fiir andere- Situationen 

45 kann es vordefinierte Tags fur alle Basiseinheiten und abgeleitete Masseinheiten geben, wie beispielsweise (ohne hierauf 
beschrankt zu sein): <Meter/>, <Kilogram/>, <Second/>, <Arnpere/>, <Kelvin/>, <Mol/>, <Candela/>, <Fahrenheit/>, 
<Celsius/>, <Inch/>, <Ampereh/>, <Percent/>. 

In einer bevorzugten Implementierung verwenden Anwendungen vordefinierte FactoryXML-Tags wenn immer mog- 
lich, urn die Moglichkeit nicht eindeutiger Wertebezeichnungen zu vermindern. Wo Werte bzw. Masseinheiten nach Gut- 

50 diinken als Textfelder codiert werden, gibt es Interpretationsbedarf. Beispiel: Das folgende FactoryXML-Datagramm - 

<sensor src^'Themometetf" t="l 8 1234"> 
<value>45.755</value> 
55 <unit>F</unit> 
</sensor> 

- verwendet keine standardisierte Einheit. Der Wert "F M fur das Element <unit> legt die Einheit Fahrenheit nahe, ist je- 
60 doch nicht eindeutig. Das folgende FactoryXML-Datagramm eliminiert jede Mehrdeutigkeit durch die Verwendung ei- 
nes vordefinierten Tags: 
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<sen'sor src='Themometer2" t=^*181234"> . 
<value>45.755</value> 
<unitxFahrenheit/x/unit> 
, </sensor> 

In einigen Implementierungen konnen spezinsche oder besonders aussagekrafuge Tags verwendet werden, um Gera- 
tezustande zusatzlich oder anstelle des <value>-Tags zu reprasentieren. So kann zum Beispiel fur ein Thermometer auch 10 
ein Tag namens <temperature> verwendet werden. In ahnlicher Weise kann in einem Durchftussmesser ein Tag namens 
<rate> verwendet werden. Einige Einheiten konnen mehrere Werte ubermitteln und hierfur unterschiedliche Tags ver- 
wenden (zum Beispiel <ratel>, <rate2> usw.). 

Ein "src "-Attribut kann verwendet werden, um die Datenquelle (d. h. die Netzwerkadresse der Datenquelle) eines Fac- 
toryXML-Datagramms kenntlich zu machen. Im Hinblick auf die vorliegende Erfindung ist mit "Netzwerkadresse" die 15 
eindeutige Adresse gemeint, die den eindeutigen Ort einer Einheit innerhalb des Systems beschreibt. Eine Netzwerk- 
adresse kann eine IP- Adresse, IPX- Adresse usw. sein, oder es kann eine symbolische Adresse sein (zum Beispiel "Ther- 
mometer2"). Quelladressen konnen frei definiert werden, um ein bestimmtes Gerat oder eine bestimmte Anwendung in- 
nerhalb eines Netzwerkes zu identifizieren. In einer bevorzugten Implementierung ist die Quelladresse ein verstandlicher 
symbolischer Name. ADD-Quelladressen miissen eindeutig sein, aber miissen nicht identisch mit Netzwerkadressen des 20 
Ubertragungsmediums sein (d. h. Hostnamen oder IP-Adressen); sie miissen auch nicht fiir ein bestimmtes Gerat iden- 
tisch sein, da auf einem Gerat mehrere Anwendungen laufen konnen, die dann unterschiedliche Adressen benotigen. 

Dariiber hinaus unterstutzt FactoryXML weltweit eindeutige Quelladressen, die von einer Koordinierungsstelle verge- 
ben werden konnen. Solch eine Adresse kann zum Beispiel in ein Peripheriegerat vbm Hersteller "eingebrannt" werden, 
so dass dieses Gerat ohne weitere Konfigurationsschritte bei Inbetriebnahme adressiert werden kann. 25 

Das "src"-Attribut ermoglicht ein sehr einfaches und genaues Mitprotokollieren von Transaktionen, da Datagramme 
sofort einem Absender zugeordnet werden konnen. Dariiber hinaus ermoglicht es die Verwendung eines Transportkanals 
fiir mehrere Gerate (Multiplexing); 

In bevorzugten Implementierungen verwendet jedes FactoryXML-fahige Gerat eine weltweit eindeutige Quell- " ^ 
adresse, die von der Koordinierungsstelle ausgegeben wird. Wo dies nicht moglich ist, kann eine andere voreingestellte 3CT* 
Quelladresse (wie zum Beispiel "ADD") verwendet werden. In diesem Fallen kann die voreingestellte Quelladresse ver- 
wendet werden, um ein Gerat zu initialisieren, so dass Anwendungen die Moglichkeit haben, festzustellen, ob das Gerat ^ 
ADD-kompatibel ist. In anderen Implementierungen kann die Verwendung einer voreingestellten Quelladresse unter- 
t bleiben. ' r . - 

Ein Datagramm kann weitere Inf ormationen eiithalten, wie in folgendem Beispiel: 35 

<set dest= ,, valve3" Sig^ ,, 0x420c4eff84ed96ac420c4efl84ed96ac >, > " — 
<actuator src=^scada" t=' , 20000101T034500" seq^'42537" Z * 
exp= ,, 20000101T110323.45Z ,, > I. 
<valuexQn/x/vaIue> 

</actuator> 
</set> 

In diesem Datagramm bezeichnet das Attribut fur die Zieladresse ("dest") die Datensenke, an die das Datagramm ge- 
sendet wird. Die Zieladresse ist identisch mit der Quelladresse des Gerats, an das das Datagramm gesendet wird. Es kann 
vordefinierte globale Adressen geben, wie "*" oder "any", die verwendet werden konnen, wenn ein Datagramm an alle 50 
Gerate bzw. Anwendungen gesendet werden soil, die iiber einen gegebenen Ubertragungskanal erreicht werden konnen. 
In einigen Implementierungen konnen im Zieladress- Attribut auch Platzhalter (Wildcards) verwendet werden. 

Ein Zeitstempel-Attribut ("t" im obigen Beispiel) kann dazu verwendet werden, den Zeitpunkt zu spezifizieren, zu 
dem das Datagramm erzeugt wurde. In bevorzugten Implementierungen haben alle Datagramme einen Zeitstempel. Die 
Verwendung von Zeitstempeln ist besonders sinnvoll in verteilten Umgebungen, bei denen Daten ohne weitere Zwi- 55 
schenschritte direkt in eine Datehbank geschrieben- werden. Fiir die Codierung von Zeitstempeln konnen verschiedene 
Methoden benutzt werden. In einer bevorzugten Implementierung kann der ISO6801 -Standard benutzt werden, um ei- 
nen Zeitstempel mit Stunden, Minuten und Sekunden ohne Doppelpunkte und Bindestriche zu erzeugen. Ausserdem 
konnen Jahr, Monat, Tag, MiUisekunden und Zulu-Zeit (UTQ angegeben werden. Fiir netzwerkfahige Gerate kann die 
Uhrzeit mit dem in RFC 1129 spezifizierten Protokoll synchronisiert werden. Fiir Gerate, die die Uhrzeit nicht berechnen 60 
konnen, kann ein voreingestellter Wert verwendet werden.. In anderen Implementierungen sind Zeitstempel optional. 

Ein Sequenz- Attribut ("seq") kann verwendet werden, um die Reihenfolge eines bestimmten Datagramms in bezug zu 
vorherigen und nachfolgenden Datagrammen kenntlich zu machen. In bevorzugten Implementierungen kann die Se- 
quenznummer als positiver ganzzahliger Wert zwischen 0 und 65535 gefuhrt werden. Bei Uberlauf kann die Sequenz- 
nummer wieder auf 0 zuriickgesetzt werden. Das Sequenz- Attribut ermoglicht es, Datenverluste und Sequenzfehier zu 65 
erkennen, die bei nicht-fehlerkorrigierenden Ubertragungskanalen (wie beispiels weise UDP) auftreten konnen. Bei der 
Verwendung von Quittungen (siehe unten) kann dadurch ein Datenverlust durch erneute Ubertragung verhindert werden. 
Beim Ubertragen von Kommandos kann die datenverarbeitende Station die Beantwortung des Kommandos eindeutig re- 
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ferenzieren. Wenn die datenverarbeitende Station eine Sequenznummer zusammen mit einem Kommando (set) oder ei- 
ner^Abfrage (poll) verwendet, kann die Antwort dieselbe Sequenznummer verwenden. 

In einigen Implementierungen kann ein Priifsummen-Attribut ("crc") verwendet werden, welches Redundanzinforma- 
tion des Datagramm-Inhalts enthalt. Die Priifsumme ermoglicht eine Fehlererkennung bei Verwendung ungesicherter 
5 Ubertragungskanale, wie zum Beispiel seriellen Asynchronschnittstellen. In bevorzugten Implementierungen wird das 
Prufsummenattribut im Quittungsbetrieb verwendet. Eine Priifsumme zusammen mit Quittungsdatagrammen kann eine 
automatische Fehlerkorrektur bereitstellen. So kann ein Empfanger zum Beispiel anhand der Priifsumme feststellen, ob 
das Datagramm fehlerfrei iibertragen Wurde. Falls nicht, kann er eine emeute Ubertragung durch Absenden einer nega- 
tiven Quittung erzwingen. Diese Prozedur wird wiederholt, bis das Datagramm fehlerfrei iibertragen wurde (d. h., bis Inr 

10 halt und Priifsumme zusammen passen). Dies ist nicht besonders sinnvoll fur TCP/IP-Ubertragungskanale, es kann aber 
wichtig fur serielle Punkt-zu-Punkt-Verbindungen und Modemstrecken sein, wo eine automatische Fehlerkorrektur nicht 
zwingend bereits durch den "Obertragungskanal vorgenommen wird. Die Implementierungsverfahren fur Priifsummen 
sind allgemein bekannt. In einer Implementierung der vorliegenden Erfindung kann die Priifsumme als CRC- 16 fur den 
Datagramm-Inhalt ohne Leerzeichen (Whitespace) und ohne die Priifsumme selbst berechnet werden. 

15 Ein Attribut fur eine digitale Signatur ("sig") kann verwendet werden, welches verschliisselte Redundanzinformation 
des Datagramm-Inhalts enthalt. In einer bevorzugten Implementierung kann die Signatur aus dem Datagramm-Inhalt mit 
dem RSA-Algorithmus berechnet werden, welcher zuvor mit der MDS-Hash-Funktion codiert wird. Ein Public-Key- 
Verfahren kann verwendet werden. Der Empfanger kann den ofFentlichen Schliissel des Senders verwenden, urn den ver- 
schliisselten Hash-Wert zu entschliisseln und mit einem zweiten, selbst aus dem Datagramm-Inhalt berechneten Hash- 

20 Wert zu vergleichen. Wenn die beideu Werte iibereinstimmen, wird der Inhalt des Datagramms als giiltig betrachtet. In ei- 
ner bevorzugten Implementierung miissen bei Verwendung einer digitalen Signatur auch eine Quelladresse, ein Zeit- 
stempel und eine Sequenznummer verwendet werden. Zur weiteren Erhohung der Sicherheit kann ein Giiltigkeitsende 
("exp") verwendet werden. Ein Datagramm mit einer digitalen Signatur darf nicht als Antwort auf ein Datagramm ohne 
Signatur oder als Antwort auf ein Datagramm mit einer ungultigen Signatur gesendet werden. Bei der Verwendung von 

25 Netzwerk-Ubertragungskanalen kann ausserdem das SSL-Protokoll (Secure Socket Layer) benutzt werden, um die Si- 
cherheit weiter zu erhohen. 

Ein Giiltigkeitsende- Attribut ("exp") kann verwendet werden, welches den Zeitpunkt deflniert, an dem oder nach dem 
ein Datagramm ungultig wird. Ein Giiltigkeitsende kann besonders sinnvoll sein, um die Sicherheit bei der Manipulation 
von Aktuatoren zu erhohen. Ohne Giiltigkeitsende kann ein auf einem "angezapften" Ubertragungskanal "mitgehortes" 

30 Datagramm (selbst dann, wenn es mit einer digitalen Signatur gesichert ist) identisch zu einem spateren Zeitpunkt erneut 
gesendet werden, um eine bestimmte Aktion zu wiederholen (zum Beispiel ein Tor, eine Sicherheitsschleuse usw. zu off- 
nen). Die Angabe eines Gultigkeitsendes (zum Beispiel eine Sekunde nachdem das Datagramm abgesendet wurde) kann 
einen Schutz gegen missbrauchlich erneut ubertragene Datagramme bieten, da sie nach dem Giiltigkeitsende vom Emp- 
fanger nicht bearbeitet werden. 

35 Einige Implementierungen der vorliegenden Erfindung konnen gespeicherte Profile verwenden. Profile konnen allge- 
mein dazu benutzt werden, um die Gesamtheit der Elemente inklusive zulassiger Wertebereiche zu beschreiben, die in 
Datagrammen fur ein bestimmtes Gerat oder eine bestimmte Anwendung benutzt werden konnen. FactoryXML-Profle 
konnen in unterschiedlicher Form spezifiziert werden. Zum Beispiel kann ein FactoryXML-Profil als XML Document 
Type Definition (DTD) ausgedriickt werden. Alternativ hierzu kann ein FactoryXML-Profil als XML Schema ausge- 

40 driickt werden. Bevorzugterweise modelliert ein Profil eine bestimmte Systemkomponente so vollstandig wie moglich. 
In einigen Implementierungen, konnen generische Profile als Ausgangspunkt fiir individuelle Profile benutzt werden. In 
anderen Implementierungen konnen FactoryXML-Profile auf der Basis standardisierter Profile modelliert werden, die 
von Standardisierungsgremien fur verschiedene Anwendungszwecke, Geratetypen und Branchen deflniert wurden. 
Ein beispielhaftes FactoryXML-Profil kann wie folgt aussehen: 

45 <!DOCTYPE sensor [ 

<!ELEMENT sensor (value, unit, error?)> 
50 <! ATTLIST sensor src CD ATA #IMPLIED dest CD ATA 
#IMPLIED t CD ATA #EV1PLIED seq CD ATA #IMPLIED 
crc CDATA #IMPLIED> 
55 <!ELEMENT value (#CDATA )?> 

<!ELEMENT Unit ANY> 
6o <! ELEMENT error (#CDATA)> 

]> 

Das dargestellte Profil ist ein generisches FactoryXML-Profil fur Sensoren (wie zum Beispiel Temperaturfiihler, 
Drucksensoren, Spannungsmesser, Waagen usw ), bestehend aus einem Element <value> und einem Element <unit>. Ein 
65 Beispieldatagramm fur einen Temperatursensor sieht folgendermassen aus: 
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<sensor src="mixer2" t="181234.90Z" seq="42537"> 

<value>45.7553</value> 

<unit><Fahrenheit/x/unit?> 
</sensor> 

Als eine Implementierungsmoglichkeit kann ein generisches FactoryXML-Profil fur Aktoren (wie Schalter, Ventile 
usw.) mit einem <value>-Element wie folgt implementiert werden: 

<!DOCTYPE actuator [ 

<! ELEMENT actuator (value, error?)> 

<! ATTLIST actuator src CD ATA #IMPLIED t CDATA #IMPLffiD 

seq CD AT A #IMPLIED> 

<!ELEMENT value (#CDATA)> 

<!ELEMENT error (#CDATA)> 

]> 

Ein beispielhaftes Datagramm zur Manipulation eines digitalen (binaren) Ausgangs (Schalters) mit diesem Profil kann 
wie folgt aussehen: 

<set dest=* > Switch5' , > 

<actuator> 

<value><On/x/value> 

</actuator> * . 

</set> *t 

Komplexe Peripheriegerate wie SPSen konnen meist nur schwer mit generischen Profilen modelliert werden. Dennoch 
lassen sich anwendungsspezifische Profile fur komplexe Peripheriegerate definieren. Ein beispielhaftes FactoryXML- 
Profil fur das Siemens-Bilderkennungssystem SIMATIC VS710 sieht folgendermassen aus: 

<!DOCTYPEvs710[ 

<! ELEMENT vs710 (program | state | monitor | readconfig | writeconfig | 

observation | error) 7> 
<!ATTLIST vs710 src CDATA #IMPLIED dest CDATA #IMPLIED t 

CDATA #IMPLIED seq CDATA #IMPLffiD sig CDATA #IMPLIED> 
<! ELEMENT program (load | reset | start | stop)> 
<!ELEMENT load (#CDATA)> 
<!ELEMENT reset EMPTY> 
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<! ELEMENT start EMPTY> 

<! ELEMENT stop EMPTY> 
5 <!ELEMENT state (#CDATA)> 

<! ELEMENT monitor (start | stop)> 
10 <!ELEMENT readconfig (#CDATA)> 

<!ELEMENT writeconfig (#CDATA)> 

<! ELEMENT observation (bitpattem | partnumber | string | float)> ( 
15 <! ELEMENT bitpattem (#CDATA)> 

<!ELEMENT partnumber (#CDATA)> 

<!ELEMENT string (#CDATA)> 

<!ELEMENT float (#CDATA)> 

<!ELEMENT error (#CDATA)> 
25 ]> 

In dieser Implementierung besteht das Peripheriegerat aus einer Kamera mit einem integrierten Prozessor zur Bilder- 
kennung, um Prozesse zum Beispiel in Zusammenhang mit Fliessbandern zu uberwachen. Die VS710 hat ein PROFI- 
BUS-Interface und eine asynchrone serielle Schnitts telle. Die asynchrone serielle Schnittstelle verwendet das 3964R- 
30 Protokoll zur Fehlerkorrektvir und ein proprietares, geratespezifisches Protokoll oberhalb von 3964R zum Kommando- 
und Datenaustausch. 

Wie gezeigt konnen FactoryXML-Profile so gestaltet werden, dass sie alle Funktionen und Eigenarten eines Gerats 
oder einer Anwendung beinhalten. Zum Beispiel kann das FactoryXML-Element "program" benutzt werden, um das 
Bilderkennungsprogramm innerhalb des VS710 zu manipulieren. Es verwendet die Unterelemente "load", "reset", "start" 

35 und "stop". Das FactoryXML-Element "monitor" startet oder stoppt die Ausgabe von Bilderkennungsergebnissen. Das 
FactoryXML-Element "observation" enthalt Ergebnisse, die vom VS710 spontan erzeugt werden, wenn die Beobach- 
tungsfunktion "monitor" eingeschaltet wurde. Die FactoryXML-Elemente "readconfig" und "writeconfig" konnen dazu 
benutzt werden, um Konfigurationsdaten zu lesen oder zu schreiben. 

Optional konnen FactoryXML-Datagramme in einen FactoryXML- "Envelope" eingeschlossen werden. Ein Facto- 

40 ryXML-Envelope ist kein FactoryXML-Element, da er mehrfache identische Unterelemente enthalten kann. Facto- 
ryXML-Envelopes konnen dariiber hinaus keine FactoryXML-Standardattribute enthalten. Ein FactoryXML-Envelope 
kann in Situationen hilfreich sein, in denen ein XML-Parser keine mehrfachen Wurzelelemente unterstutzt. Ein beispiel- 
haftes FactoryXML-Datagramm in einem FactoryXML-Envelope kann wie folgt aussehen: 

45 <FactoryXML version-" \A yy > 
<status> 

<sensor src="mixer2 5, > 
50 <value>44.534<yvalue> 

<unit><Kilogram/></units> 
55 </sensor> 
</status> 
</FactoryXML> 

60 

UTV 

Die vorliegende Erfindung sieht die Verwendung alternativer Datenformate vor. Eines dieser altemativen Datenformat 
wird als UTV bezeichnet, ein Akronym for "unstructured tag/value". Ein sehr einf aches UTV-Datagramm kann wie folgt 
65 aussehen: 

src = Thermometer2 
t = 234412 
value = 1.92 
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• **'.■ 

unit = Celsius " 

Wie man sieht, enthalt UTV ahnlichen Inhalt wie FactoryXML, aber die Daten weisen eine geringere Strukturierung 
auf. Bei UTV-Codiening kann ein Tag von einem optionalen Wert gefolgt werden. Tags und Werte konnen zum Beispiel 
durch ein Gleichheitszeichen voneinander abgetrennt werden; Tags ohhe Werte entsprechen leeren FactoryXML-Ele- 
menten. Vordefinierte Tags (wie <Kg/>, <On/>, <Ofi/>) konnen in UTV wie Werte behandelt werden. Multiple Tags 
konnen durch Leerzeichen (Whitespace) voneinander abgetrennt werden. Als Leerzeichen konnen gelten (ohne An- 
spruch auf VoUstandigkeit): [SP] (ASCII-Zeichen 32), "und"-Zeichen ("&"), Pluszeichen ("+"), Tabulatoren, Wagen- 
riicklaufe ([CR], ASCII-Zeichen 13) und Zeilenvorschiibe ([LF], ASCII-Zeichen 10). Elemente und Attribute werden in 
UTV im allgemeinen syntaktisch gleich behandelt. Das folgende Beispieldatagramrn enthalt den selben Inhalt wie das 
obige Beispiel, verwenden aber andere Trennzeichen: 
src = Themometer2&t = 23441 2& value = 1 .92&unit = Celsius 

Einige UTV-Implementierungen konnen ubergeordnete Elemente enthalten, um mehr Information und Struktur zu 
ubermitteln. Ubergeordnete Elemente konnen als Prafixe codiert werden, wobei zur Abtrennung des Prafixes ein Punkt 
verwendet wird. Ein beispielhaftes Datagramm dieser Implementierung kann wie folgt strukturiert sein: 
sensor, src = Thermometer2 
sensor.t = 2344i2 
sensor, value = 1 .92 
sensor, unit = Celsius 

UTV kann in Situationen verwendet werden, in denen die Zielanwendung nicht in der Lage ist, FactoryXML zu ver- ' 
arbei ten oder in denen FactoryXML einfacri unpraktisch ware. UTV erfordert paketorientierte Ubertragungskanale, bei 
denen das Ubertragungsprotokoll die Kennzeichnung des Nachrichtenendes (bzw. Datagrammendes) unterstutzt. Sirin- 
volle Ubertragungskanale fiir UTV beinhalten (ohne Ausschliesslichkeit): HTTP Clients, die Geratezustande an einen 
HTIP-Server mittels URI-Codierung ubermitteln (da URI-Codierung FactoryXML nicht unterstutzt, wohl aber UTV); 
HTTP Server, die passive Transaktionen mittels URI-Codierung akzeptieren; SMS-Gateways (bidirektional), da aktive 
Alarm-Transaktionen UTV verwenden konnen, um Alarmnachrichten an Handy-Displays (als UTV-Datagramm codiert) 
zu ubertragen, auf welche ein Benutzer mit der Ruckiibertragung einer UTV-codierten SMS-Nachricht antworten kann, 
die er auf der Tastatur seines Handies eingetippt hat und die auf der anderen Seite zu Konfigurationsanderungen oder 
ahnlichem fuhrt; WAPAVML Clients aufgrund der eingeschrankten Darstellungsmoglichkeiten bei WAP; Alarmierung 
und Femkonfiguration per Email; und einfache HTML-Seiten fiir Browser, die XML nicht unterstiitzen. 

Transaktionen 

Kommandos konnen an eine Automatisierungskomponente mit dem Standardelement "set" gesendet werden. In einer 
bevorzugten Implementierung wird ein Kommando mit dem neuen bzw. aktueUen Geratezustand quittiert. Wenn das 
"seq"-Attribut (Sequenznummer) verwendet wird, wird die Automatisierungskomponente beyorzugterweise denselben 
"seq"-Wert in ihrem Antwortdatagramm verwenden. Die folgende Ablauftabelle verdeutlicht die Inhalte eines Datag- 
rammaustauschs, bei dem eine DS ein Kommando an eine AK (zum Beispiel einen binaren Aiisgang) sendet, den Zu- 
stand "On" zu setzen: 



Datenverarbeitende Station 


Automatisierungskomponente - 


<set dest="Switch5"> 
<actuator seq="12"> 

<value><On/x/value> 
</actuator> 
</set> . 






<status> 

<actuator src="Switch5 // seq="12"> 

<value><On/x/value> 
</actuator> 
</status> 



In der dargestellten Transaktion sendet die DS ein Kommando an eine AK mit der Netzadresse "Switch5 M . Das Kom- 
mando lautet, dass der Inhalt des Elements <value> auf den' Wert "On" gesetzt werden soil. Die DS verwendet die Se- 
quenznummer 12 zur Kennzeichnung dieser Transaktion. Die AK antwortet mit einem Datagramm, welches den neuen 
Wert enthalt, und zeigt damit an, dass das Kommando erfolgreich ausgefuhrt wurde. Das Antwortdatagramm verwendet 
dieselbe Sequenznummer wie das Kommandodatagramm, so dass die Antwort eindeutig dem Kommando zugeordnet 
werden kann. 

Im Fehlerfall enthalt das Antwortdatagramm den tatsachlichen Wert des betreffenden Elements, zusammen mit einem 
<error>-Element, welches eine Fehlerbeschreibung enthalt. Die folgende Ablauftabelle stellt den Austausch von Datag- 
rammen dar, bei dem eine DS Kommandos an eine AK (zum Beispiel einen digitalen Ausgang) schickt, um einen - nicht 
unterstutzten - Zustand "high" einzuschalten. 
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Datenverarbeitende Station 


_ . v. ._ ... 

Automatisierungskomponente 


5 


»-> ~ V- V-iCOL — OWJ.LU11J *r 












<value>hiah< /value> 






</arfuat*or> 










10 










<status> 






Octuator src="Switch5" seq="12"> 






<value><Off/x/value> 


15 




<error>il legal value</error> 






</actuator> 






</status> 



20 Wie zu sehen ist, schlug diese Transaktion fehl, da die DS versucht hat, den Wert "high" einzustellen, die AK jedoch 

nur die Werte "On" und "Off" unterstutzt. 

Das Akzeptieren von Kommandos durch eine Systemkomponente kann per Konfiguration auf Kommandos von be- 

stimmten Stationen (identifiziert durch ihre Quelladresse) beschrankt werden. Zusammen mit der Netzwerkadresse (so- 

fern vorhandeh) und mit der digitalen Signatur lasst sich die Kommandoubergabe auf ausgewahlte Stationen beschran- 
25 ken, wodurch Missbrauchsmoglichkeiten eingeschrankt werden. 

Das Standardelement <poll> kann dazu verwendet werden, einen Gerate- oder Anwendungszustand abzufragen. Eine 

Abfrage-Transaktion ist ahnlich einer Kommando-Transaktion. Wenn <poll> als leeres Element verwendet wird, enthalt 

das Antwortdatagramm eine vollstandige Datenstruktur des abgefragten Gerats bzw. der abgefragten Anwendung. 

<poll> kann jedoch auch dazu benutzt werden, bestimmte Unterelemente gezielt abzufragen. Die folgende Beispiel- 
30 Transaktion veranschaulicht den Inhalt von Datagrammen, mit denen eine DS ("erp") den Zustand einer AK ("ramp") ab- 

fragt: 



Datenverarbeitende Station 


Automatisierungskomponente 


<poll src="erp" dest="ramp"/> 






<status dest="erp"> 
<sensor src=' , ramp // t="092312"> 

<value>545 . 32</value> 
<unit><Kg/x/unit> 
</sensor> 
</status> 


Die folgende Beispiel-Transaktion zeigt, wie eine DS den Inhalt eines bestimmten Unterelements abfragen kann: 


Datenverarbeitende Station 


Automatisierungskomponente 


<poll src= // erp' / dest^"ramp"> 

<sensorxunit/></ sensor > 

</poll> 






<status dest="erp"> 

<sensor src="ramp^ t="092312"> 

<unit><Kg/x/unit> 

<7sensor> 

</status> 



Aktive Transaktionen 

65 Aktive Transaktionen werden spontan von einer AK initiiert. Die Ausgabe erfolgt zyklisch, bei Zustandsanderung 
oder beim Eintreffen bestimmter Bedingungen. In bevorzugten Implementierungen konnen aktive Transaktionen (spe- 
ziell solche, die durch Zustandsanderungen ausgelost werden) durch die Verwendung von Quittungen gegen Datenver- 
lust geschiitzt werden. 
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Bei einer aktSven zyklischen Datenausgabe kann eine AK Datagramme zyklisch in vordefinierten Zeitintervallen (zum 
Beispiel jede Sekunde) absenden. In vielen Situationen wird allerdings die aktive Ausgabe bei Zustandsanderungen vor- 
zuziehen sein, da sie die Netzwerklast reduziert und die Programmierung der DS vereinfacht. 

Bei, einer aktiven Datenausgabe bei Zustandsanderungen kann eine AK ein Datagramm im Fall eines Zustandswech- 
sels absenden. Ausserdem kann der aktuelle Zustand der AK beirn Verbindungsaufbau oder beim Einschalten des Gerats 
(fur verbindungslose Ubertragungskanale) gesendet werden. Aktive Datenausgabe bei Zustandsanderungen ermoglicht 
eine erhebliche Reduktion der Komplexitat von Softwareanwendungen, die die Daten auswerten, und tragt ausserdem 
dazu bei, die Netzwerklast zu reduzieren. Fur verbindungslose oder ungesicherte Ubertragungskanale konnen Quittun- 
gen benutzt werden, um Datenverluste zu vermeideri, die sonst zu schwerwiegenden Storungen fuhren konnten. 

Bei der aktiven Datenausgabe beim Eintreten bestimmter Bedingungen (Alarmierung) kann eine AK ein Datagramm 
abschicken, wenn eine oder mehrere Bedingungen erfullt sind. Die Bedingungen konnen einfach oder komplex sein. 

In bevorzugten Implementierungen konnen aktive Transaktionen von der DS quittiert werden, um zii verhindern, dass 
Datagramme nicht verloren gehen, speziell wenn nicht fehlerkorrigierende Ubertragungskanale wie UDP verwendet 
werden. Im Quittungsbetrieb wartet eine AK auf eine Quittung fiir jedes Datagramm, bevor das nachste Datagramm 
ubertragen wird. Eine Quittung kann ein leeres Wurzelelement mit der Sequenznummer des empfangenen Datagramms 
sein. Alternativ konnen die Standardelemente <ack> und <nak> verwendet werden. Der Vbrteil hiervon ist, dass damit 
auch negative Quittungen moglich sind, wodurch eine Transaktion bei einem gestorten Ubertragungskanal beschleunigt 
wird (der Sender muss nicht erst bis zum Ablauf seines Timeouts warten). Die folgende Transaktion veranschaulicht den 
Quittungsbetrieb: 



Datenverarbeitende Station 


Automatisierungskomponente 




<status ack="yes" ref=="iuf 2"> 
<sensor src= // ramp5" seci="12"> 

<value>442 . 23</value> 
<unit><Kg/x/unit> 
</sensor> 
</status> 


<ack dest="ramp5' / ref ="iuf 2"/> 





Bei Verwendung fehlererkennender Ubertragungskanale wie UDP braucht nicht unbedingt ein Prufsurnmenattribut 
verwendet zu werden, Priifsummen werden vorzugsweise auf nicht fehlergesicherten Ubertragungskanalen wie seriellen 
Asynchronschnittstellen verwendet. 

Wenn die datenerzeugende Station innerhalb einer vordefinierten Zeit (Timeout) keine Quittung erhalt, kann das letzte 
Datagramm emeut ubertragen werden, bis eine Quittung empfangen wird oder eine vordefinierte maximale Zahl von 
Wiederholungen erreicht ist. Keine Folgedatagramme soUten ubertragen werden, bevor einegultige Quittung empfangen 
wurde. . 

Quittungen sind besonders sinnvoll in Verbindung mit der aktiven Datenausgabe bei Zustandswechsel. Die aktive Da- 
tenausgabe bei Zustandswechsel ist vorteilhaft, da sie die Programmierung vereinfacht und die Netzlast reduziert. Diese 
Ubertragungsart kann jedoch zu fatalen Konsequenzen fuhren, wenn Datenverluste unbemerkt bleiben. Der Quittungs- 
betrieb kann benutzt werden, um solche Datenverluste bei nicht fehlerkorrigierenden Ubertragungskanalen wie UDP zu 
verhindern. 

Anmeldung und Abmeldung (subscribe/unsubscribe) 

Die Zieladresse fiir aktive Transaktionen kann typischerweise auf zwei Arten festgelegt werden: (1) fest konfiguriert 
innerhalb eines Gerates oder einer Anwendung, (2) dynamisch durch Anmeldung und Abmeldung. Eine dynamische An- 
meldung und Abmeldung ist insbesondere sinnvoll fiir verbindungslose Ubertragungskanale wie UDP. Sie kann mit den 
Standardelementen "subscribe" und "unsubscribe" implementiert werden. Eine Station, die sich bei einem ADD-Gerat 
mit "subscribe" anmeldet, erhalt Ausgaben von diesem Gerat je nach tier vorkonligurierten Betriebsart (zum Beispiel ak- 
tive zyklische Datenausgabe), bis sie sich mit "unsubscribe" wieder abmeldet. 

An- und Abmeldung konnen ADD-Kommandos sein. Eine An- und Abmeldung kann von der AK quittiert werden. 
Die folgenden Attribute konnen bei der Anmeldung verwendet werden: 
< LATTLIST subscribe 
trigger (cyclicldeltalalarm) #IMPLIED 
* ack (yeslno) #IMPLIED> 

Das Attribut "trigger" legt fest, ob die Ausgabe zyklisch (cyclic), bei Zustandsanderungen (delta) oder beim Eintreffen 
bestimmter Bedingungen (alarm) erfolgt. Das Attribut "ack" legt fest, ob Quittungen gesendet werden oder nicht. 

Einige Implementierungen der vorliegenden Erfindung konnen An- und Abmeldetransaktionen verwenden. Eine bei- 
spielhafte An- und Abmeldetransaktion kann wie folgt aussehen: 
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Datenverarbeitende Station 


Automatisierungskomponente 


5 


<subscribe> 

<sensor src^'^rp" dest="ramp2"/> 
</subscribe> 




10 




<ack src="ramp2" dest="erp"/> 


15 




<status dest="erp"> 

<sensor src="ramp2" t="092312"> 

<value>123 . 2</vaIue> 

<unit><Kg/x/unit>. 

</sensor> 

</status> 


20 
25 




<status dest="erp"> 

<sensor src="ramp2" t="092313"> 

<value>123 . 2</value> 

<unit><Kg/x/unit> 

</sensor> 

</status> 


30 




<status dest="erp"> 

<sensor src="ramp2" t="092314 "> 

<value>123. 9</value> 

<unit><Kg/x/unit> 

</sensor> 

</status> 


35 


<unsubscribe src^'erp" 
dest="ramp2"/> 








<ack src="ramp2" dest="erp"/> 



40 In diesem Beispiel meldet sich eine DS bei einer Waage ("ramp2") an, die daraufhin zyklisch (jede Sekunde) Datag- 
ramme an die DS sendet, bis sich die DS mit "unsubscribe" wieder abmeldet. An- und Abmeldung werden von der AK 
quittiert. 

In einigen Fallen kann die DS eine Transaktionsbetriebsart wahlen, der sich von der voreingestellten Betriebsart un- 
terscheidet. Dies geschieht dadurch, dass Werte fur die Attribute "trigger" und "ack" gesetzt werden. Die folgende Ab- 
45 lauftabelle stellt eine beispielhafte Transaktion dar, die veranschaulicht, wie eine Einheit sich fur aktive Datenausgabe 
bei Zustandswechsel mit Bestatigungen anmelden kann: 
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Datenverarbeitende Station 


Automatisierunpskomnonente 


<subscribe src="erp" dest="ramp2" 
trigger=»''delta'' ack="yes"/> 






<ack src="ramp2" dest="erp"/> 




<status dest="erp" ack='<yes" 
ref="8ifl"> 

<sensor src="ramp2" t="092312" 
seg="0"> 

<value>123 . 2</value> 
vunitxvtvg/ -><*/unit> 
</sensor> 
< /status > 


<ack src= ,, erp ,/ dest="ramp2" 
ref="8ifl"/> 




- 


<status dest="erp" ack="yes" 
ref="98p"> 

<sensor src-"ramp2" t="092314" 
seq="l"> 

<value>123 . 9</value> 
<unit><Kg/></uni^> 
</sensor> 
</status> 


<ack src= ,/ erp' / dest="ramp2" 
ref="98p"/> 


•- 


<unsubscribe src="erp" 
dest="ramp2"7> 






<ack src="rainp2" dest="erp" 
t-"092314"/> 



15 



Hier meldet sich die DS fur aktive Datenausgabe bei Zustandswechsel mit Bestatigungen an. Die AK beginnt die Aus- 
gabe mit der Sequenznummer 0. Das batagramm wird von der DS quittiert. Um 09:23: 13 Uhr gibt es keine Ubertragung, 45 
da sich der Geratezustand (in diesem Fall das gemessene Gewicht) nicht geandert hat. Die nachste tFbertragung erfolgt 
urn 09:23:14 Uhr, da sich das Gewicht von 123.2 auf 123.9 Kilogramm verandert hat. Wieder wird das Datagramm quit- 
tiert, und anschliessend meldet sich die DS ab. 

Bei der Anmeldung kann auch ein gultiger Wertebereich fur ein besdmmtes Element festgelegt werden. Dies ist sinn- 
voll fur Alarmierung, wobei unterschiedliche Anwendungen unterschiedliche Schwellwerte definieren konnen. Im Alar- 50 
mierungsbetrieb wird eine Ausgabe ausgelost, wenn Werte ausserhalb des zulassigen Bereichs fallen. Die Ausgabe wird 
bei Zustandswechseln fortgesetzt, bis der Wert des betreffendeh Elements wieder innerhalb des giiltigen Bereichs liegt, 
oder die Ausgabe kann zyklisch fur erne vordefinierte Zeit fortgesetzt werden. Zur Definition eines gultigen Wertebe- 
reichs konnen die Standardelemente "min", "max", "equal" und "unequal" benutzt werden. 

Die folgenden Beispiele erlautem (sowohl in FactoryXML als auch in UTV) Datagramme zur Anmeldung, die in un- 55 
terschiedlichen Situadonen benutzt werden konnen. Im folgenden Beispiel meldet sich eine DS fur Alarmierung an, falls 
der Wert des Elements "temperature" den Wert 1 10.9 uberschreitet oder den Wert 34.2 unterschreitet: 



60 



65 
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FactoryXML 


UTV 


<subscribe trigger="alarnr ack="no"> 

<temperature> 

<min>34.2</min> 

<max>l 1 0.9</max> 

</temperature> 

</subscribe> 


subscribe.trigger==alarm 

subscribe.ack=no 

subscribe temnerature min :=: 34 2 

subscribe.temperature.max==l 1 0.9 ! 



Das folgende Beispiel zeigt, wie sich eine Anwendung fur Alarmierung anmelden kann, wenn der Wert des Elements 
"gateS" auf den Wert "Open" wechselt: 



FactoryXML 


UTV 


<subscribe trigger="alarm" ack="no> 
<gate5> 

<equalxOpen/x/equal> 

</gate5> 

</subscribe> 


subscribe.trigger=alarm 
subscribe. ack=iio 
subscribe. gate5 . equal=Open 



Das nachste Beispiel zeigt, wie sich eine Anwendung fur Alarmierung anmelden kann, wenn das Element "color" ei- 
nen anderen Wert als "green" einnimmt: 



FactoryXML 


UTV 


<subscribe triggei="alarm" ack-"no> 
<color> 

<unequal>green</unequalx/color> 
</subscribe> 


subscribe.trigger=alarni 
subscribe. ack=no 
subscribexolor.unequal=green 



Die Definition von Alarmbedingungen kann die Elemente "max", "min", "equal" und "unequal" verwenden. Das Ver- 
mischen dieser Elemente (mit Ausnahme von "max" und "min") innerhalb einer Bedingungsdefinition ist unzulassig und 
unsinnig. "max" und "min" konnen zusammen oder einzeln benutzt werden. 



Ubertragungskanale 

Keines der Datenformate, die in der vorliegenden Patentschrift beschrieben sind, ist an ein bestimmtes Transportme- 
dium oder -protokoll gebunden. Dennoch werden in der Praxis bevorzugt Implementierungen mit TCP/IP oder verwand- 
ten Intemet-Protokollen anzutreffen sein. 

Implementierungen der vorliegenden Erfindung konnen mehrere unterschiedliche Ubertragungskanale verwenden, 
einschliesslich einfacher Transportprotokolle (ISO/OSI-Schicht 4) und Anwendungsprotokolle (ISO/OSI-Schicht 7). In 
der Praxis werden bevorzugt Implementierungen mit Transportprotokollen anzutreffen sein, da sie flexiblere und effi- 
zientere Moglichkeiten des Datenaustauschs erlauben. 

In einer . Form der Implementierung fungiert die AK als TCP Server und wartet auf Verbindungsanfragen. Eine DS 
kann eine Verbindung als TCP Client aufbauen, um Kommandos an die AK zu senden und/oder urn Daten von der AK zu 
empfangen. Diese Art des tjbertragungskanals kann alle FactoryXML-TVansaktionen unterstiitzen. Ein Quittungsbetrieb 
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ist hier allerdirigs nicht sinnvoll, da TCP bereits fehlerkorrigierend ist. Uber diesen Kanal kann auch eine An- und Ab- 
meldung (subscribe/unsubscribe) erfolgen, wobei die AK aktiv eine TCP-Client- Verbindung zur DS aufbaut, ein Datag- 
ranun ubermittelt, und die TCP-Verbindung wieder schliesst. 

In einer anderen Implementierung kann die AK als TCP Client fungieren und Verbindungen zu einem vorkonfigurier- 
teri TCP Server aufbauen, um Datagramme zu ubermitteln. Als Alternative zu fest konfigurierten Verbindungen konnen 5 
auch* Verbindungen zu DS aufgebaut werden, die sich zuvor uber einen TCP-Seirverkanal bei der AK angemeldet haben . * 
(subscribe). Dieser tJbertragungskanal.ist in erster Linie sinnvoll fur aktive (spontane) TYansaktionen. Die Verwendung 
von Bestatigungsdatagrammen ist auf dieseni Ubertragungskanal nicht sinnvoll, da TCP bereits fehlerkorrigierend ist. 

Ans telle von TCP kann auch UDP verwendet werden. UDP hat gegeniiber TCP einige yorteile, unter anderem bessere 
. Performance durch geringeren Protokoll-Overhead, paketorientierte gegenuber dateristfomorientierter Ubertragung und 10 
Unterstutzung yon Broadcasts. Auf der anderen Seite ist UDP zwar fehlererkennend, aber nicht fehlerkorrigierend, so 
dass Paketverluste als Folge von Ubertragungsfehlem auflreten konnen. Ausserdern konnen UDP-Datagramme beim 
Empfanger in der falschen Reihenfolge eintrefferi. FactoryXML lost diese Probleme durch die Verwendung von Se- 
quenznummern. Sequenznummern konnen dazu verwendet werden, Datenverluste und Sequenzfehler zu erkennen. 

Datenverluste sind im Abfragebetrieb ("poll") moglicherweise nicht kritisch, da die DS das Ausbleiben einer Antwort 15 
auf ihre Abfrage erkennt und die Abfrage darauf hin erneut starten kann. Auch bei der aktiven (spontanen) zyklischen 
Ausgabe von Daten ist der Verlust einzelner Datenpakete normalerweise unkritisch, da ein "Update" der Daten automa- 
tisch im nachsten Zyklus erfolgt. Werden bei der spontanen Datenausgabe nur Anderungsdaten (oder Alarmierungsda- 
ten) iibertragen, empfiehlt sich dagegen die Verwendung eines anderen Transportprotokolls als UDP oder die Benutzung 
des Quittungsbetriebs. In dieser Betriebsart ist der mit den Quittungen verbundene Protokolloverhead fur gewohnlich ak- 20 
zeptabel, da eine Anderung der Daten, die zum Absenden eines Datagramms fuhrt, vergleichsweise selten in den Be- 
triebsarteri auftritt,,in denen dieses Verfahren normalerweise benutzt wird. 

In Verbindung mit UDP sind die Anmeldung und Abmeldung fur spontane Datagramme (subscribe/unsubscribe) be- 
sonders sinnvoll. Eine DS kann sich als UDP Client bei einer AK, die als UDP Server fungiert, anmelden (subscribe). 
Nach der Anmeldung werden die Rollen vertauscht und die AK sendet Anderungsdaten an die DS, die dann UDP-Da- 25 
tagramme empfangt. f - 

Alternativ zu TCP und UDP konnen auch andere Internet-Protokolle wie zum Beispiel T/TCP (TCP for Transactions, . 
siehe RFC 1379 und RFC 1644) verwendet werden. T/TCP bietet einen sehr viel schnelleren Verbindungsauf- und -ab- 
bau als TCP und ist von der Performance her mit UDP vergleichbar, ist jedoch fehlerkorrigierend wie TCP. Im Hinblick 
auf die vorliegende Erfindung ist T/TCP eine bevorzugte schnellere Alternative zu TCP. 30 

Sowohl FactoryXML als auch UTV konnen beliebige datenstromorientierte Transportkanale nutzen, wie zum Beispiel 
serielle Asynchronschnittstellen, ISDN oder USB. In der Praxis werden Implementierungen mit fehlerkorrigierenden 
Protokollen bevorzugt. Bei der Verwendung von fehlererkennenden, aber nicht fehlerkorrigierenden Protokollen konnen ' 
die in FactoryXML vorgesehenen Quittungen verwendet werden, um Datenverluste zu verrneiden. Fiir UTV sind fehler- 
korrigierende, paketorientierte Ubertragungskanale erforderlich. 35 

Implementienmgen der vorliegenden Erfindung konnen auch HTTP als Ubertragungskanal nutzen. Der ^Sbrteil von 
HTTP ist die grosse Anzahl von installierten HTTP Servern und Clients (d. h. Web-Browsern) weltweit. Der folgende 
Abschnitt beschreibt unterschiedliche Arten der Benutzung von HTTP zusammen mit der vorliegenden Erfindung, stellt 
dabei jedoch keine vollstandige Liste moglicher Impementierungen dar. 

40 

HTTP Server, POST-Methode 

Ein HTTP-POST-Befehl einer DS (der HTTP Client) kann benutzt werden, um ein FactoryXML-Datagramm (zum 
Beispiel mit einem <set>- oder <poll>-Datagrairim) zu einer AK (dem HTTP Server) zu schicken. Die AK kann mit ei- 
nem FactoryXML-Datagramm antworten. Eine weitergehende Datenausgabe der AK ist nur moglich, wenn die unterlie- 45 
gende TCP-Verbindung offen gehalten wird. 

HTTP Server, GET-Methode . 

Eine HTTP-GET- Anfrage (zum Beispiel mit einem "set"- oder "polT-Standardelement) kann von einer DS ausgelost 50 
werden, wobei ein UTV-Datagramm innerhalb des URI transportiert wird. Beispiele hierfur sind die URIs "http://lights- 
witch5?set.actuator. value = on"und "http://themometer27poll.sensor.unit". Die AK, die als HTTP Server fungiert, kann 
mit einem FactoryXML-Datagramm antworten. Weitere Ausgaben der AK sind moglich, sofem die unterliegende TCP- 
Verbindung geoffnet bleibt. 

' , ' 55 

HTTP Client, POST-Methode 

. Dieser Ubertragungskanal ist sinnvoll fiir Anwendungen, bei denen eine AK Daten durch Ausfiillen eines "Web-For- 
mulars" ubermitteln soli, oder wo einfach die weit verbreitete CGI^Technik genutzt werden soli, um betriebswirtschaft- 
lichen Anwendungen Automatisierungsdaten zur Verfugung zu stellen. Der HTTP Server kann zum Beispiel eine be- 60 
triebswirtschaftliche Anwendung sein, die so konfiguriert ist, dass sie die Sendedaten einer AK (zum Beispiel ein UTV- 
Datagramm) mit einem CGI-Script verarbeiten kann. Die AK (der HTTP Client) muss in geeigneter Form fur aktive Da- 
tenausgabe konfiguriert sein, in der Regel fur Ausgaben bei Zustandswechsel oder beim Eintreten vordefinierter Bedin- 
gungen. 

65 

HTTP Client, GET-Methode 

Eine AK meldet sich als HTTP Client bei einer DS (dem HTTP Server) an und ubermittelt ein UTV-Datagramm als 
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Teil des URI. Ein Beispiel hierfur ware der URI "http://server?src = thermometer2&value = 23.442&unit = Celsius" . Der 
HTTP Server kann darauf mit einem FactoryXML-Datagramm antworten, welches von einem CGI-Script generiert wird. 
Dieser tJbertragungskanal ist sinnvoll fur aktive Datenausgabe bei Zustandswechsel oder beim Eintreten vordefinierter 
.Kriterien. 

5 Email kann als Ubertragungskanal benutzt werden und ist besonders sinnvoll fiir Alarmierung und Femwartung. 
Email- Versand kann fur aktive Datenausgabe einer AK genutzt werden. Die AK kann ein UTV-Datagramm zu einer vor- 
konfigurierten Email- Adresse senden oder an einen entfemten Benutzer, der sich per "subscribe" angemeldet hat Email- 
Empfang kann fur Fernkonfiguration verwendet werden. Ein entfemter Administrator kann Befehle in UTV- (oder Fac- 
toryXML-) Codierung absenden, die mit dem Internet-Email^Protokoll iibertragen werden konnen. Email-Empfang kann 

10 ausserdem fur die Anmeldung ("subscribe") fiir aktive Datenausgabe verwendet werden, wobei die aktive Datenausgabe 
dann an die Email- Adresse des entfernten Administrators per Email- Versand geschickt werden kann. Kommandos konne 
sowohl in das Betreff-Feld der Email als auch in den Email-Inhalt geschrieben werden. 

Andere Implementierungen der vorliegenden Erfindung verwenden drahtlose Ubertragungskanale wie SMS und WAP. 
Handys haben eine besondere praktische Bedeutung fur Alarmierung, Femwartung und Fernkonfiguration. Praktisch je- 

15 der Wartungsingenieur im Aussendienst verfugt fiber ein Handy. Ausserdem sind Handies in der Lage, ASCQ-Textnach- 
richten (SMS) zu empfangen und zu senden und dienen als eingeschrankte Zugangsmoglichkeit zuni Internet per WAP. 
Beide Moglichkeiten machen sie zu geeigneten und attraktiven Terminals fiir ADD. 

SMS-Nachrichten sind kurze Ibxtnachrichten (maximal 160 Zeichen) die auf dem Handy-Display ausgegeben werden 
konnen oder auf der Tastatur des Handies eingegeben werden konnen. Die aktive Datenausgabe einer AK aufgrund von 

20 Zustandswechseln oder aufgrund des Eintretens vordefinierter Bedingungen kann UTV-codiert zu einem oder mehreren 
Handys per SMS geschickt werden. Je nach SMS Service Center kann es unterschiedliche Zugangsmoglichkeiten geben, 
um in das Funknetzwerk zu gelangen. Die Zugangsmoglichkeiten umfassen normalerweise Email, Analogmodem, 
ISDN, und GSM-Modem; alle diese Moglichkeiten konnen auf einfache Weise von ADD-Geraten unterstutzt werden. 
Fiir alle Zugangsmoglichkeiten zum SMS Service Center ausser Email kann es wunschenswert sein, ein SMS-Netzwerk- 

25 Gateway zu installieren, welches mehrere Anwendungen bzw. Gerate innerhalb des Netzwerks benutzen konnen. AK 
konnen per Handy durch Verwendung von SMS-Nachrichten manipuliert werden. 

Einige Handies konnen bereits im Internet "Browsen", indem sie das Wireless Application Protocol (WAP) fur Daten- 
ubertragung unterstiitzen und die Wireless Markup Language (WML) zur Darstellung der Daten. WML ist eine Unter- 
menge von HTML. WAP ermoglicht die Abfrage von ADD-Geraten durch "Browsen" durch Menus und Hotlinks und 

30 kann fiir Ferndiagnose und Femwartung eingesetzt werden. 

WAP ist jedoch ungeeignet fur Alarmierung und aktive Datenausgabe in einigen Implementierungen, da ein Periphe- 
riegerat per WAP moglicherweise nicht aktiv an ein Handy senden kann. 

Die vorstehenden Beispiele wurden geschildert, um bestimmte Implementiemngen der Erfindung zu erlautern. Tech- 
nisch kundige Leser sollten die in den Beispielen dargestellten Techniken bitte als solche verstehen, die der Erfinder als 

35 gut funktionierend fiir die praktische Umsetzung der Erfindung erkannt hat und die deshalb als bevorzugte Verfahrens- 
weisen bei ihrer praktischen Umsetzung betrachtet werden konnen. Technisch kundige Leser sollten jedoch auch verste- 
hen, dass zahlreiche Anderungen innerhalb bestimmter hier dargelegter Implementiemngen der Erfindung vorgenom- 
men werden konnen, die dennoch zu einem gleichen oder ahniichen Resultat fuhren, ohne vom Geist und vom Geltungs- 
bereich der Erfindung abzuweichen. 

40 

Patentanspriiche 

1. Ein System zur Verteilung von Automatisierungsdaten (ADD), bestehend aus: 
einer datenverarbeitenden Station (DS) mit einer Netzwerkadresse; 

einer Automatisierungskomponente (AK) mit einer Netzwerkadresse und funktional verbunden mit der DS; 
in dem besagte DS und besagte AK so konfiguriert sind, dass sie mittels einer oder mehrerer Transaktionen mitein- 
ander kommunizieren, wobei besagte Transaktion aus einem Datagramm besteht, wobei das Datagramm vollstan- 
dig codiert ist und eine Beschreibung in Klarschrift enthalt. 

2. Das ADD-rSystem rtach Anspmch 1, in dem besagtes Datagramm des weiteren ein Quell-Attribut zur Kennzeich- 
nung der Netzwerkadresse der Quelle des Datagramms enthalt. 

3. Das ADD-System nach Anspmch 1, in dem besagtes Datagramm des weiteren ein Ziel-Attribut enthalt, welches 
die Netzwerkadresse der intendierten Datensenke fiir dieses Datagramm enthalt. 

4. Das ADD-System nach Anspmch 1, in dem besagtes Datagramm des weiteren enthalt: 
ein Wert-Attribut, sowie 

ein Einheit-Attribut, welches die von besagtem Wert-Attribut verwendete Einheit angibt. 

5. Das ADD-System nach Anspmch 1, in dem besagtes Datagramm des weiteren ein oder mehrere Sichheitsattri- 
bute enthalt. 

6. Das ADD-System nach Anspmch 5. in dem mindestens eines der besagten Sicherheits attribute aus einem Attri- 
but mit einer digitalen Signatur besteht. 

7. Das ADD-System nach Anspmch 5. in dem mindestens eines der besagten Sicherheits attribute aus einem Giil- 
tigkeitsende-Attribut besteht, welches einen Zeitpunkt angibt, nach welchem besagtes Datagramm ungiiltig wird. 

8. Das ADD-System nach Anspmch 1, in dem besagtes Datagramm des weiteren ein Zeitstempel-Attribut beinhal- 
tet, welches den Zeitpunkt angibt, an dem besagtes Datagramm erzeugt wurde. 

9. Das ADD-System nach Anspmch 1, in dem besagtes Datagramm des weiteren ein oder mehrere Attribute zur 
Fehlersicherung beinhaltet. 

10. Das ADD-System nach Anspmch 9, in dem besagtes Datagramm des weiteren ein Prufsummen-Attribut um- 
fasst, welches Redundanzinformation des Inhalts von besagtem Datagramm enthalt. 

11. Das ADD-System nach Anspmch 9, in dem besagtes Datagramm des weiteren ein Sequenznummer-Attribut 
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enthalt. "' 

12. Das ADD-System nach Anspruch 1, welches des weiteren ein Profil enthalt, welches die in besagtem Datag- 
ramm zulassigeri Elemente, Parameter und Attribute spezifiziert. 

1 3. Das ADD-System nach Anspruch 12, in welchem besagtes Profil ein Datagramrn zur Verwenduhg mit einer be- 
stimm|:en Art AK spezifiziert. 

1 4. Das ADD-System nach Anspruch 1 , in welchem besagtes Datagramni einen Zustand besagter AK reprasentiert. 

15. Das ADD-System nach Anspruch 1, in welchem besagtes Datagramrn ein Kommando von besagter DS an be- 
sagte AK reprasentiert. , - 

16. Das ADD-System nach Anspruch 1, in dem besagte Transaktion des weiteren ein Quittungsdatagramm bein- 
haltet, mit dem der erfolgreiche oder nicht erfolgreiche Empfang besagten Datagramms angezeigt werden kann. 

1 7. Das ADD-System nach Anspruch 1 , in dem besagte Transaktion (en) eine aktive Transaktion ist. 
18.. Das ADD-System nach Anspruch 1, in dem besagte Transaktion(en) eine passive Transaktion. ist. 

19. Das ADD-System nach Anspruch 1, welches des weiteren eine Koordinierungsstelle enthalt, welche funktional 
mit besagter/besagten DS und mit besagter/besagten AK gekoppelt ist, wobei besagte Koordinierungsstelle besag- 
ten DS und AK Netzwerkadressen zuweisen kann. 

20. Das ADD-System nach Anspruch 1, in dem besagtes Datagramrn das FactoryXML-Format verwendet. 

21. Das' ADD-System nach Anspruch 1, in dem besagtes Datagramrn das UTV-Format verwendet. 

22. Ein System zur Verteilung von Automatisierungsdaten, bestehend aus: 
eine Planungsebene, bestehend aus 

einem Planungsnetzwerk, und einer oder mehrerer DS, die funktional mit besagtem Planungsnetzwerk gekoppelt 
sind; 

einer Steuerungsebene, bestehend aus 

einem Steuerungsnetzwerk und einer oder mehreren AK, die funktional mit besagtem Planungsnetzwerk gekoppelt 
sind; und 

einer oder mehrerer Gateway-Einheiten, die funktional mit besagtem/n AK 
und mit besagtem Planungsnetzwerk verkniipft sind, 

wobei besagte Gateway-Einheit(en) dazu dierien, besagte DS darin zu unterstutzen, mit besagten AK zu kommuni- 
zieren, indem sie ein oder mehrere Datagramme generieren und zu besagten AK senden, wobei die Datagramme 
vollstandig codierte Beschreibungen in Klarschrift enthalten; und 

wobei besagte AK mit besagter/n DS dadurch kommunizieren konnen, dass sie ein oder mehrere Datagramme 
durch besagte Gateway-Einheiten zu besagten DS senden konnen. 

23. Ein Datagramrn zur Verwendung in einem System zur Verteilung von Automatisierungsdaten, bestehend aus ei- 
nem AK, welches funktional mit einer DS gekoppelt ist, wobei das Datagramrn beinhaltet: . * 

ein Quell- Attribut, welches die Datenquelle besagten Datagramms identifiziert, wobei besagte Datenquelle die AK 
oder die DS sein kann; 

ein Ziel-Attribut, welches eine Datensenke besagten Datagramms identifiziert, wobei besagte Datensenke die AK 
oder die DS sein kann; r 
wobei besagtes Datagramrn vollstandig codiert ist. 

24. Ein Verfahren zur automatisierten Datenverteilung in einem System bestehend aus einer Quelleinheit, welche 
funktional mit einer Zieleinheit gekoppelt ist, wobei das Verfahren beinhaltet: 

eine Quelleinheit, die ein Datagramrn generiert, welches aus vollstandig codierten Beschreibungen in Klarschrift 
besteht; und 

einer Zieleinheit, die besagtes Datagramrn empfangt und auf den Inhalt besagten Datagramms sinnvoll antwortet. 

25. Das Verfahren zur automatisierten Dateniibertragung nach Anspruch 24, in dem besagte Quelleinheit eine DS 
ist, welche ein Abfrage-Datagramm an besagte Zieleinheit (eine AK) sendet, und besagte Zieleinheit mit dem Sen- 
den eines Datagramms zu besagter Quelleinheit antwortet, wobei das Datagramrn ein Wert-Attribut und ein zuge- 
horiges Einheiten- Attribut enthalt. 

26. Das Verfahren zur automatisierten Datenverteilung nach Anspruch 24, in dem des weiteren besagte Quellein- 
heit eine AK ist, die aktiv ein oder mehrere Datagramme generiert und besagte ein oder mehrere Datagramme an be- 
sagte Zieleinheit beim Eintreten eines vordefinierten auslosenden Ereignisses sendet. 
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